LINUX.ORG.RU

Вышел компилятор языка D LDC 1.0

 ,


1

7

Данное событие является очень важным в расширении применения языка D. Благодаря компилятору LDC у D теперь появилась полная поддержка архитектуры ARM и практически полная поддержка разработки под Android (включая графические приложения на базе dlangui). Также LDC поддерживает линковку с Objective-C-кодом. На данный момент доступны готовые сборки как под Windows, так и под Linux.

Следует отметить, что LDC основан на LLVM и позволяет генерировать хорошо оптимизированный код, значительно более оптимизированный, чем при использовании референсного компилятора dmd. Данная версия LDC базируется на LLVM 3.8.0.

>>> Подробности

★★

Проверено: Falcon-peregrinus ()
Последнее исправление: DeadEye (всего исправлений: 4)

Ответ на: комментарий от menangen

Тот же офф компилятор dmd (референсный) пишет человек 20

Откуда дровишки?

eao197 ★★★★★
()
Ответ на: комментарий от menangen

Сборщики мусора, кстати, написаны и для компилируемых языков по типу C/C++.

примеры в студию

anonymous
()
Ответ на: комментарий от Evil_And

C++ мог бы прокатить, если бы вендор железок был единственный, как у iOS. А им надо было обеспечить кросс-платформенность

C++ запросто обеспечивает кроссплатформенность на железе и у них тогда был только arm

anonymous
()
Ответ на: комментарий от menangen

Не вбрасывайте, а то сейчас прибегут разрабы на юнити. Ваш покорный слуга, анонимус, тоже вот целых 3 года пилил большую говноигру на юнити, и даже в стиме релизнулся. Но юнити, это такое лютое говнище, что пожалуй оно только антирекламу для C# делает. Вся суть юнити - это быстрое прототипирование, весь движок сделан так чтобы как можно быстрее можно было наговнокодить рабочий «прототип» для раннего доступа в стиме. Когда дело доходит до НОРМАЛЬНОЙ разработки - то либо приходится выбрасывать к херам весь прототип и делать с нуля, но вдумчиво, параллельно мучаясь и борясь с багами юнити, либо допиливать прототип, получая на выходе овердофига багов, которые никто кроме изначальных разрабов игры пофиксить не может. Длительная поддержка проектов на юнити, это вообще отдельная боль для отдельной темы.

anonymous
()
Ответ на: комментарий от anonymous

Вцелом это так. По мне так, главный недостаток D - это отсутствие хорошей IDE типа Eclipse с плагином, покрывающим 100% стандартной библиотеки и т.п., рефакторинга, отладчика и всего этого интегрированного в единую ide. Если бы они написали хорошие плагины, удобный отладчик для java движка eclipse или idea - вот тогда бы народ подтянулся. А так, сейчас на D только сервера можно писать, и то..в качестве тестового прототипа. Мало кто из компаний, у кого много «легаси» c++ кода, будет переписывать свой код на D - это очень трудозатратно, а выхлоп мизерный. Ну, а новые проекты тоже начинать никто не хочет - все боятся разбираться и учиться заново, писать библиотеки, обёртки. Хоть это и делается не сложно, всё-таки на это нужно прилично времени - а это удорожание разработки.

menangen ★★★★★
()
Ответ на: комментарий от andreyu

Потому что в C++ любые изменения в библиотечных классах ломают ABI. Можно даже ничего не меняя получить проблем, просто взяв другую версию компилятора. А в джаве можно вот такое делать:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
    toolbar.setElevation(10f);
}

pftBest ★★★★
()
Ответ на: комментарий от menangen

Компиляция D в байткод .NET?

Нет, не просто компиляция, а возможность взаимодействия с библиотеками .NET. Как IronPython, например. Такого нет, как выше выяснили. Ну или хорошо конспирируются.

anonymous
()
Ответ на: комментарий от uin

Вы таки просто не умеете его готовить.

anonymous
()

Читаю комментарии и думаю: а как получилось, что C++ взлетел в свое время?

anonymous
()
Ответ на: комментарий от anonymous

Эх, дикое время было... А вообще, как мне кажется, он просто был первым, вот и всё. Сами посудите - совместимость с C, наличие огромного числа наработок на C, сравнимая производительность C++. Были-ли вообще альтернативы для C++ в то время по перечисленным параметрам ? Если-бы уже в тот момент придумали-бы D - то, думаю, он-бы взлетел также как и C++. Ну разве только сборки мусора-бы не было.

anonymous
()

LDC основан на LLVM и позволяет генерировать хорошо оптимизированный код, значительно более оптимизированный, чем при использовании референсного компилятора dmd.

Вот на «значительно более оптмиизированный» хотелось бы пруфов.

hobbit ★★★★★
()
Ответ на: комментарий от anonymous

Были-ли вообще альтернативы для C++ в то время по перечисленным параметрам ?

Pascal (ObjectPascal), Modula-2, Oberon, Ada, Eiffel. И это только те, чьи названия остались в истории.

Совместимость с C у них была та еще, но по скорости работы были не очень далеко, а по безопасности так и заметно получше.

На момент своего появления C++ был сильно не таким, как сейчас. ЕМПИН, исключения и шаблоны сильно позже добавились (и это в описании языка, в компиляторах они стали доступны еще позже). Тогда как обобщенное программирование в Ada уже было.

Так что C++ брал не только своей производительностью и совместимостью с C, но и чем-то другим.

eao197 ★★★★★
()
Ответ на: комментарий от menangen

главный недостаток D - это отсутствие хорошей IDE

Это правда. Только не «уровня ушлёпочного эклипса», а уровня MS VS. Надеюсь, говоря всё это, вы пробовали VisualD? Много ли у него ограничений, мешающих эффективно работать?

matumba ★★★★★
()
Ответ на: комментарий от EXL

> А опенсорс комьюнити как писали на C/C++, так и будут до скончания веков.
И это хорошо. Сколько этих новомодных язычков погибло уже?

И это плохо. Когда один предлагает ездить на бензине, тысячи остолопов не понимают перспектив и продолжают стегать лошадь. Вот примерно так выглядят все эти наколенные сипипи-проектики линупсоидов.

Ди - это луч света в беспросветном царстве переполнений и уязвимостей, коим кишит сипиписный опенсорс. «С++ - это нунчаки программирования: в руках профессионала творят чудеса, но для остальных 99% - это бесконечные удары себе по лбу» (ц) я.

matumba ★★★★★
()
Ответ на: комментарий от anonymous

Вот скажите, какой смысл переходить на D человеку, пишущему 5 лет на C++?

Человеку пишущему 5 лет на С++ пора бы на собственный опыт ориентироваться, а не советы с форума.

DarkEld3r ★★★★★
()
Ответ на: комментарий от anonymous

Рулит не тот, у кого язык круче, а тот у кого ресурсов для его продвижения больше -> а значит больше проектов -> больше разработчиков -> больше наработок -> больше готовых решений.

PHP FTW!!!

anonymous
()
Ответ на: комментарий от anonymous

а как получилось, что C++ взлетел в свое время?

Всякие там борланды, винда, симбиан C++, всякие beos и иже с ними. Со стороны UNIX'ов эти ваши Qt и протокеды. Тогда «C с классами» были короной ынтерпрайза.

Именно промышленные стандарты и огромная куча кода на C, с которым C++ имел возможность сопряжаться без усилий, сделали такую популярность весьма посредственному язычку.

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от eao197

но и чем-то другим

Неплохая реализация ООП, а по ООП тогда ведь все тащились. Это тоже сыграло свою роль, не так ли?

EXL ★★★★★
()
Ответ на: комментарий от anonymous

Сборщики мусора, кстати, написаны и для компилируемых языков по типу C/C++.

примеры в студию

Boehm garbage collector

anonymous
()
Ответ на: комментарий от EXL

Неплохая реализация ООП, а по ООП тогда ведь все тащились.

В середине 80-х ООП еще не было таким мейнстримом, как в конце 90-х и начале 2000-х. Многие разработчики тогда просто не знали, что это такое. Сейчас, впрочем, тоже.

Ну и в Eiffel-е ООП было (да и есть) еще лучше.

Это тоже сыграло свою роль, не так ли?

Сыграло, на мой взгляд, то, что C++ стал одним из немногих (а может и единственным) языком, который позволял делать легковесные реализации абстракций. Изначально за счет ООП, затем еще и за счет обобщенного программирования.

Но вот это сочетание выразительной мощи, высокой эффективности и низкой ресурсоемкости, плюс легкий доступ к низкоуровневым вещам, в те времена оказалось в наличии только в C++. Тот же Eiffel из-за GC оказывался более требовательным к ресурсам.

Да, в общем-то и сейчас, если нужно написать что-то сложное для устройства с 1MiB RAM и тактовой частотой в 10MHz, то выбор будет ну совсем небольшим. А ведь уже 30 лет прошло.

eao197 ★★★★★
()
Ответ на: комментарий от makoven

А опенсорс комьюнити как писали на C/C++, так и будут до скончания веков.

Ну почему? Могут перейти на свифты и шарпы всякие...

А вообще не о чем тут сожалеть: если инструмент удобен, то им будут пользоваться. Да, деньги решают, но ведь они тоже создают (как правило) «удобство» в виде библиотек.

Ну а если что-то не нравится, то ты ведь тоже часть «сообщества». Можно брать и пилить что-то на «правильном» языке.

DarkEld3r ★★★★★
()
Ответ на: комментарий от EXL

Неплохая реализация ООП

Да ладно...

anonymous
()
Ответ на: комментарий от menangen

Звучит как фанатизм - «почти», «примерно», «можно», «легко». А как оно на деле?

andreyu ★★★★★
()
Ответ на: комментарий от EXL

И это хорошо. Сколько этих новомодных язычков погибло уже?

С одной стороны, да. С другой - «погибают» ведь не обязательно плохие языки. Сложно побороть инертность, легаси и недостаток библиотек/инструментов. Можно, конечно, сказать, что преимущества недостаточны раз не перевешивают это всё, но иногда всё-таки хочется «чего-то более современного».

DarkEld3r ★★★★★
()
Ответ на: комментарий от EXL

Где выпилили тормозную Java-J2ME, и впендюрили C++, Cascades на C++, Qt на C++ и QtQuick.

Тащемта там скорее подействовала упоротость маркетоидов Сана с их лицензионной политикой.
Потому-то Андроид на Далвике и начали пилить, а не на Java2ME.

WatchCat ★★★★★
()
Ответ на: комментарий от menangen

Не мало, тот же Unity пишут на C#,

В каком месте юнити пишут на шарпе? То, что под юнити пишут на шарпе, не значит, что сам движок на шарпе. Насколько мне известно, там плюсы во все поля.

andreyu ★★★★★
()
Ответ на: комментарий от menangen

На Unity же много игр написано?

90% говна размером под предыдущее ограничение размера apk (50mb), которое лучше не видеть вообще

И особо никто не жалуется ни на тормознутость, ни на «сборщик мусора».

Еще как жалуются. Тормозит и не стесняется.

andreyu ★★★★★
()
Ответ на: комментарий от anonymous

Вот нафига нужен UFCS

В плюсы тоже хотят добавить. Да и экстеншн методы из C# - разве по сути не то же самое?

миксины те-же ?

А с ними что не так?

Встроенное UNIT-тестирование - это хорошо, ВОТ ТОЛЬКО ЗАЧЕМ ЭТО ТЯНУТЬ В ЯЗЫК ?

Потому что удобно. Не надо в каждом отдельном проекте разбираться с чем-то новым. И да, мне попадалось немало самопального для плюсов.

Стандартная библиотека D - вообще тема для отдельного обсуждения...

Послушал бы с удовольствием, на D не пишу, если что.

DarkEld3r ★★★★★
()
Ответ на: комментарий от pftBest

Потому что в C++ любые изменения в библиотечных классах ломают ABI.

Не любые, но да, нужно делать дополнительные приседания и выстрелить в ногу проще.

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

Не любые, но да, нужно делать дополнительные приседания и выстрелить в ногу проще.

В принципе, практические любую функциональность можно добавить в любую библиотеку без поломки совместимости. Только часть можно реализовать только за счет сжирания ресурсов процессора.

Что бы не жрать процессор надо применять методы разработчиков Qt.

x86_64 ★★★
()
Ответ на: комментарий от hobbit

dmd, как референсный компилятор, вообще не заморачиваться оптимизацией (кроме случаев, когда это явно прописано). Там другая задача.

arkadij-smirnov
()
Ответ на: комментарий от x86_64

надо применять методы разработчиков Qt

Ога, C++ у нас недостаточно извращенный язычок, давайте его еще сверху MOC'ом обмажем. А вместо процессора будем жрать мозг того, кто будет все это поддерживать.

anonymous
()
Ответ на: комментарий от arkadij-smirnov

dmd
Там другая задача

У D нет задач же. Нету. В 2005 году это был перспективный экспериментальный язычок. Сейчас - мертворожденное поделие. Да еще и само с собой не совместимое - D1 и D2. Единственная компания, которая известна использованием D (социомантик в смысле), до сих пор использует D1 - это даже не смешно.

anonymous
()
Ответ на: комментарий от uin

У Си есть один существенный недостаток - он весь костыльный и на нем теперь можно только говенный код писать.

Ну вы поняли, что мешает плохому танцору))

anonymous
()
Ответ на: комментарий от anonymous

А что за проблема со стандартными библиотеками у D2? Юнит тестирование в самом языке тоже не плохая идея. UFCS? Ну не нравится не ешьте, запретите в полисях проекта это использовать. Миксины туда же.

anonymous
()
Ответ на: комментарий от anonymous

У D нет задач же. Нету. В 2005 году это был перспективный экспериментальный язычок. Сейчас - мертворожденное поделие. Да еще и само с собой не совместимое - D1 и D2. Единственная компания, которая известна использованием D (социомантик в смысле), до сих пор использует D1 - это даже не смешно.

Ну ты наркоман... Еще про то, что 10 лет назад было две библиотеки Phobos и Tango.

Xroft ★★
() автор топика
Последнее исправление: Xroft (всего исправлений: 1)
Ответ на: комментарий от Xroft

Еще про то, что 10 лет назад было две библиотеки Phobos и Tango.

Причем Tango был значительно лучше Phobos-а. Да и сам D больше напоминал правильно сделанную Java для нейтива, нежели C++переростка с alias this, invariant, @pure и пр.

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

Задачи, которые стоят перед D, здесь не при чем. Референсный компилятор это, фактически, демка, предназначенная для демонстрации возможностей языка. Оптимизацией и т.д. там никто заниматься не будет

arkadij-smirnov
()
Ответ на: комментарий от anonymous

Ога, C++ у нас недостаточно извращенный язычок, давайте его еще сверху MOC'ом обмажем. А вместо процессора будем жрать мозг того, кто будет все это поддерживать.

Вы явно говорите о том, о чем представления не имеете. Несколько правил позволяет разработичкам Qt легко соблюдать обратную совместимость. Это очень просто.

x86_64 ★★★
()
Ответ на: комментарий от x86_64

Несколько правил

В нормальных языках/платформах таких правил просто не требуется - обратная совместимость (и вообще совместимость между компонентами) идет из коробки. И разработчикам не требуется для каждого класса кодить opaque pointer'ы и выверять что все классы на стыке модулей на Q начинаются.

У C++ безусловно есть своя ниша, но какая-либо совместимость, переносимость и компонуемость в его достоинства явно не входит. Тролли накодили свой собственный Q-мирок на pre-standard С++, потому-что ничего лучше на тот момент не было.

anonymous
()
Ответ на: комментарий от anonymous

У C++ безусловно есть своя ниша, но какая-либо совместимость, переносимость и компонуемость в его достоинства явно не входит.

В C++ это все есть, но на уровне исходного кода. Как и любых других сложных языков без специализированного промежуточного представления (вроде байт-кода JVM или MSIL). У обсуждающегося здесь D, например.

eao197 ★★★★★
()
Ответ на: комментарий от Xroft

Ну ты наркоман...

Ну так тред про D же, что здесь делать нормальным людям.

D умер в тот момент, когда его решили строить вокруг GC - бороться с Java на ее поле - вот где настоящая наркомания. Там, куда Java по различным причинам не добирается, теперь есть Rust/C++14 (низкоуровневые вещи), Nim (метапрограммирование), Go (специализированный серверсайд) и Swift («среднеуровневые» вещи).

anonymous
()
Ответ на: комментарий от eao197

В C++ это все есть, но на уровне исходного кода

Даже на уровне исходного кода все очень грустно. Сравни «компонуемость» (т.е. легкость разработки библиотек и их подключения к проектам) в C++ против Rust и Go. Промежуточного представления у них тоже нет, а компонуемость на порядки лучше.

anonymous
()
Ответ на: комментарий от anonymous

Даже на уровне исходного кода все очень грустно.

Уже давным-давно все не так грустно, как вы пытаетесь изобразить. Причем перестало быть грустно за несколько лет до начала работ над Rust и Go.

eao197 ★★★★★
()

Каждый раз одно и тоже - куча людей под новостью, которые на D не пишут и им по больей части на него плевать - пишут о том что он не взлетел и не нужен.

На форуме имени операционки, которая не взлетела и не нужна, ага.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.