LINUX.ORG.RU

Вышла очередная референсная реализация компиляторов языков D1 и D2

 ,


1

3

10 июля стала доступна для загрузки очередная референсная реализация компиляторов языков D1 и D2. Как повелось с предыдущего выпуска, готовы пакеты для Ubuntu, Fedora, и openSUSE, как 32-х, так и 64-хбитные.

Некоторые нововведения:

  • введены атрибуты @safe, @property, сделан автоматический интерфейс для @safe, pure, nothrow;
  • В inline assembler добавлена поддержка инструкций SSSE3;
  • добавлены новые предупреждения о свойствах, подлежащих удалению, часть свойств объявлены удалёнными;
  • расширены ядро языка и стандартная библиотека, в частности, добавлены core.sys.posix.netdb, td.array.uninitializedArray, std.array.minimallyInitializedArray;
  • часть функций, в первую очередь в модулях std.string и std.uni, была переименована для соответствия с разработанными правилами именования, старые названия частично сохранены для совместимости, но будут удалены из последующих версий;
  • добавлена возможность использовать логические переменные в качестве ключей в ассоциативных массивах, ранее с этою целью можно было использовать только целые числа и строки.

Авторы также рапортуют об устранении 127 ошибок различной природы.

Подробный список изменений можно посмотреть на официальном сайте.

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

★★★★★

Проверено: Shaman007 ()
Последнее исправление: adriano32 (всего исправлений: 1)

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

На «интерфейс» и «реализацию»? Похоже ты с 89 года так и не осилил основные парадигмы ООП.

Как эти парадигмы помешали сделать сделать Java?

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

Не больше гемора, чем из любого другого языка сишный код вызывать. C++ не считаем - это особый случай (:
Скорость у D, кстати, действительно хорошая. Я тут just for fun пилю компилятор диалекта Lisp на D, и сканер (лексический анализатор) выдаёт скорость порядка 13 Мб/с, в то время как сишная версия - 23 Мб/c, притом что сишную я писал раза в четыре дольше, постоянно матерясь и изобретая велосипеды, уже встроенные в D. Ну, и объём кода сканера: D - 410 строка, C - 595 строк. Для C почти 200 строк сверху и в 4 раза больше времени на разработку, а прирост скорости всего-то в два раза - это знак.

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

> Не больше гемора, чем из любого другого языка сишный код вызывать

да, просто почему-то считал, что конвертация C -> D будет совсем тривиальной и автоматической, хотя наверное она таковой и может быть, просто не докрутили еще

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

> Задумка у D, конечно, интересная: «С++ с человеческим лицом».

Идея хорошая, правда, С++, как я понимаю, тоже затевался как «С с человеческим лицом». Во многом, кстати, получилось.

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

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

> вот обычно сначала спецификацию разрабатывают, а потом по спецификации делают проект.

обычно

Спасибо, улыбнул...

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

> Ниша системного программирования давно и плотно занята С, С++ и АДА.

Эта «занятость» ничуть не мешает начинать новые проекты на Ди. Более того - учитывая намного большую безопасность Ди как языка, его просто необходимо везде внедрять. Вот есть куча всяких sendmail'ов, apache, MySQL, etc - весь этот хлам можно очень даже красиво и аккуратно переписать, чтобы хотя бы не лажать с переполнением стека или «очень длинных команд» и т.п.

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

Отчасти это верно, но разработчиков видимо чем-то он не устраивает, раз они слезают с него и возвращаются на старый добрый Цпп или жабу. OpenMW тому пример.

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

XOmB is 64 bit and multi core only. No support for anything else is currently planned

Ну и вообще у них написано, что проект чисто для развлечения и самосовершенствования. Никаких практических целей их проект не преследует.

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

>К слову, АБ был написан года два назад, периодически перекомпилировал - из заявленных breaking changes меня коснулись только регэкспы и стринги, обновил _10_ строк кода. Это так много, что ЛОРчане готовы обкакаться от «нестабильности языка»???

вопрос как опытному по теме - бывают ли у них такие «breaking changes», которые не вылавливаются перекомпиляцией, а приводят к runtime errors?

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

sendmail как минимум, лет 20 разрабатывался и тестировался в условиях промышленного использования под реальными нагрузками, в этом его основная ценность. Новоделы не нужны, найдется очень мало админов-эксплутационников, желающих пройти по новому набору граблей.

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

> но разработчиков видимо чем-то он не устраивает...

Этому может быть мильён субъективных и 10 объективных причин. Я думаю, побеждают субъективные - «не такие названия классов», «нет плюшечек в IDE», «влом писать поиск» и.т.п. Я писал на Ди - ну ни грамма отличий от Си! Все заковыки только от непривычных библиотек (да и те написаны вполне стандартно). Т.е. если человека поставить раком, за пол-года он будет уже матёрый спец по «Дям». А если как на ЛОРе каждый будет капризничать, конечно язык не продвинется! И ведь что смешно - себе же врут... Не писали ни строчки кода, а флейма уже на 100 комментов - ну не цирк? :)
Я не был бы так настойчив, если бы сам Ди не юзал - просто удивляешься некомпетентности критикующих.

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

> вопрос как опытному по теме - бывают ли у них такие «breaking changes», которые не вылавливаются перекомпиляцией, а приводят к runtime errors?

Практически не встречал. Я ж говорю, язык ШЛИФУЕТСЯ, никаких серьёзных вывертов Уолтер не планирует. Наоборот, то, что валилось по эксепшыну, начинает работать (напр. traits).
Он не меньше нашего хочет вывести язык в массовое применение, поэтому в любой момент доступна последняя стабильная версия - только пробуйте!

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

> sendmail как минимум, лет 20 разрабатывался

Это ни о чём не говорит, dmesg тоже не «салага» (см. посл. новость) :) и что? 20 лет по 50 функций в день добавлялось? Скорее, наоборот - раз в неделю ловили баги, которые в Ди в принципе нельзя совершить.
Да и не в sendmail дело - просто если потихоньку перетрясать весь шлак, доставшийся нам из 70-ых, можно более оптимально и устойчиво переписать те утилиты и библиотеки, что уже есть. Например, те же граф. форматы - из всех уродцев, напложенных 10 лет назад, сейчас выжили gif, tif, png и jpeg. ОДНА либа с их поддержкой будет прекрасной заменой всем этим libtiff & Co. А натренировавшись на либах (априори не особо связанных с множеством других либ), можно уже «замахнуться на Шекспира» (т.е. сендмэйлы и т.п.).

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

>поэтому в любой момент доступна последняя стабильная версия - только пробуйте!

надо будет еще разок попробовать (предыдущие попытки как-то быстро увядали).
еще vala хочется, но ее внутреннее состояние вызывает отвращение...

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

> да, просто почему-то считал, что конвертация C -> D будет совсем тривиальной

Есть одна тонкость - внешне (на уровне for, if, etc) они идентичны, но т.к. Ди более безопасен, для её обеспечения он использует другие примитивы. Если у нас есть Сишный указатель, конвертер просто не способен понять, либо это архитектурная необходимость, либо это простой массив и его можно записать как int[] arr;
Но всё же, благодаря почти полному внешнему и семантическому сходству, конверсия не является чем-то особо трудным.

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

> надо будет еще разок попробовать

:) Да даже компилить ничего не надо! Раззиповать dmd и поставить пути на */linux/bin32(64). А уж скорость компилляции вообще световая.

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

> Раззиповать dmd

я пользуюсь gdc 4.4 из репозитория убунты - есть смысл или лучше таки dmd? и еще вопрос - из IDE кроме Eclipse + DDT под линукс больше ничего нет?

aho
()

Не упомянули очень значимые изменения: * Pointers are now supported in CTFE * Heap-allocated structs are now supported in CTFE

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

> я пользуюсь gdc 4.4 из репозитория убунты - есть смысл или лучше таки dmd?

Я не использую ldc - это отдельный проект и «LDC already compiles a lot of D code, but should still be considered beta quality».
Есть ведь официальный линукс бинарь - зачем усложнять жизнь? :) Ради пары оптимизированных инструкций? Вот когда будет НЕХВАТАТЬ CPU, тогда уже можно почесать затылок.

из IDE кроме Eclipse + DDT под линукс больше ничего нет?


scite4d - заточка scite под D. Но я «виндузятник», мне ближе VisualD (плагин к студии).

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

Извиняюсь, перепутал: есть ведь ещё и LDC, а вы о GDC :) Не, его я тоже не юзал.

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

compile time evaluation functions

constexpr, не? Не вижу особого современного подхода в compile time evaluation functions. Какая часть вашей программы будет написана с использованием этого подхода? 1%, 0.5%, меньше?

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

С C/C++ не совместим

собственно, это главное отличие от плюсов. Плюсы развиваются так, чтобы была обратная совместимость. Поэтому синтаксис будущих плюсов подгоняется под старые. Хорошо, когда ты можешь писать код на С++0х и при этом использовать библиотеки на С++03 или С++98. А эти парни пошли другим путем, они плевали на совместимость. И они тоже правы. Так проще переделать язык, чем подгонять под старое.

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

> Ада же.

Лень лезть в Вики, но, ЕМНИП, разработка спецификации Ады шла лет 6 - при том, что за ней стояло американское МО; годные компиляторы появились еще через год-два. Не вижу особого преимущества подхода «сначала спецификация».

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

> Но с переходом к С++ разделение на заголовок и реализацию уже начинает заметно доставать.

С переходом к C++ реализации перекочевали в заголовки - см., например, Boost, там .cpp вообще нет.

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

я пользуюсь gdc 4.4 из репозитория убунты - есть смысл или лучше таки dmd?

Для D1 практически нет смысла. Для D2 лучше использовать dmd, поскольку gdc не только отстаёт по версиям, но и хватает дополнительные глюки.

и еще вопрос - из IDE кроме Eclipse + DDT под линукс больше ничего нет?

Использовал vim и geany, хотя они могут считаться IDE только условно. После достаточно долгих камланий удалось заставить работать с ним CodeBlocks.

Vudod ★★★★★
() автор топика
Ответ на: compile time evaluation functions от galanthus

constexpr, не? Не вижу особого современного подхода в compile time evaluation functions. Какая часть вашей программы будет написана с использованием этого подхода? 1%, 0.5%, меньше?

На самом деле небольшая, но в ряде случаев это сильно экономит место и нервы. Если та или иная функция может возвращать достаточно часто некоторое выделенное значение, её можно переделать в 2 и поставить условный оператор, чтобы сократить расчёт. Данное свойство позволяет с этим не заморачиваться.

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

Отчасти это верно, но разработчиков видимо чем-то он не устраивает, раз они слезают с него и возвращаются на старый добрый Цпп или жабу. OpenMW тому пример.

Во-первых, это инертность мышления. Вспомните, сколько лет перелазили с С на кресты, несмотря на обратную совместимость последних. Многие так и не перелезли до сих пор, наплодили Java, objective C, Vala и ещё тьму поделок.

Во-вторых, D1 уже живой труп, а D2 ещё недоделан. Поэтому никто сейчас не будет делать на нём гигантских проектов.

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

> Но с переходом к С++ разделение на заголовок и реализацию уже начинает заметно доставать.

Мне, кстати, кажется, что оно, наоборот, дисциплинирует. Сначала обдумываем интерфейс, потом детали. Да и понять, что модуль делает, с выделенной интерфейсной частью проще.

Хотя кодеров, у которых скорость вылезания кода обгоняет скорость мышления, это раздражает.

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

Мне, кстати, кажется, что оно, наоборот, дисциплинирует. Сначала обдумываем интерфейс, потом детали. Да и понять, что модуль делает, с выделенной интерфейсной частью проще.

Не знаю, не не нравится. В сях почти не писал, но в Паскале интерфейсная часть довольно бессмысленна. Хотя там по крайней мере догадались не пихать её в отдельный файл.

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

>Да и понять, что модуль делает, с выделенной интерфейсной частью проще.

В заголовочном файле тоже можно отдельно описывать интерфейс и реализацию.

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

Насчет IDE. Какую можете посоветовать для D?

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

>Лень лезть в Вики, но, ЕМНИП, разработка спецификации Ады шла лет 6 - при том, что за ней стояло американское МО; годные компиляторы появились еще через год-два. Не вижу особого преимущества подхода «сначала спецификация».

Если верить вики, спеки делались 3 года и компилятор 2,5 года. Сравним с D, который появился в 99-ом.

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

Вы говорите про борландовскую реализацию Паскаля. (В оригинале модулей не было вообще.)

А в Модуле-2, которую делал сам Вирт, интерфейс и реализацию вот именно растащили по раздельным файлам. Причём не с помощью #include-костылей, как в сях. В Модуле-2 это языковые логические конструкции.

И считаю, что Вирт был прав.

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

> Задумка у D, конечно, интересная: «С++ с человеческим лицом». Очень нравится автоматическая, а так же и явная сборка мусора. Жаль, что так долго и медленно развивается.

C++ by design поддерживает реализацию мусоросборника. Надо несколько функций реализовать и не использовать ничего для динамики кроме new. Не надо было для этого изобретать очередной велосипед. А вообще тем, кто хочет улучшать C++ надо сначала прочесть «Дизайн и эволюция С++». Если желание строить велосипеды не пропадет, надо еще раз прочесть. Если таки осталось, то скорее всего идея стоит реализации. А для гарбажа да пропертей не стоит даже париццо.

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

> давно известно, что «с++ с человеческим лицом» - это джава

Жава - это недо-С++. Все, что отцы объявили пороком в С++, когда свою жабу рисовали, их глупы дети таки реализовали. И множественное наследование (через интерфейсы) и типонезависимые контейнеры (через generic). Осталось только перееопределение операторов сделать и тогда это будет уже С++ в байт-коде :)). Гляда на это, задаешься вопросом: Насколько идеи, лежащие в основе жабы были изначально порочны? Чем ява сильна, так это стандартами и библиотеками. В остальном - унылое поделие, с тяжелой виртуальной машиной и нынешним хозяином.

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

> Хотелось бы услышать наоборот: «вот я делаю проект, а в языке вот такая беда - ...».

Вот же бред. Вот нету в паскале возможности программисту легально написать функцию с переменным числом параметров, хотя и write и read это делают. Тут же прибежит подобного плана умник и скажет, что это небезопасно и страшно. И вам это лучше делать через указатели, свои классы или еще как (грамотный программист и так это знает). Так если это страшно, какого хера писали write/read??? И как? Грязными хуками, потому что дизайн языка кривой!

По ссылке сходил. Выходит все, что хотят добавить так это непонятное: абсолютно портабельный код (вспоминаем проблемы жабы), безопасный с точки зрения орфографии синтаксис (вспоминаем проблемы python), «безопасную» работу с памятью (вспоминаем опять про жабу и скриптовые языки, в которых еще не сделана нормальная сборка мусора), к тому же как писали ранее от нее таки отказались, не? Еще какие цели у языка? Поломать бинарную совместимость с С++, оставив её с С; воткнуть в язык строки (которые потянут кучу дополнительного функционала от substr до fill), но прибить множественное наследование; внедрить в язык RTI; отказаться от namespaces в пользу модулей; и самое главное (!) отменить Future declaration и не использовать в нотации темплейтов символы <>.

Какой-то симплифаед С++ и все. Все эти фишки не обеспечат написание хорошего кода при отсутствии головы на плечах. Это же новая система ограничений и сомнительной полезности фич. И если вам все это надо, чтобы писать бесопасный, нормальный код, то вам лучше задуматься о смене профессии! Из-за того, что вы не умеете нормально ходить на двух ногах (писать на С++), вы по всему маршруту вашего следования поставили перила и лавочки (нашли/изобрели D(или любую другую хрень)). Вам страшно от мощи имеющегося инструмента, вы нашли или сделали себе девайс попроще. Ваше право, но надо кричать, что неосиленный вами инструмент плох. В глазах тех, кто знает, вы выглядите глупо.

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

> Ди ни разу не ФП, можете считать его «ООЯ с элементами ФП».

Блин, ты хоть сам-то ходил по ссылке, куда всех посылаешь? === Major Design Goals of D ... 4. Support multi-paradigm programming, i.e. at a minimum support imperative, structured, object oriented, generic and even functional programming paradigms. ... ===

Где тут ооя с элементами фп? Где вообще сказано, что D - ооя?

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

> Большинство было брошено еще 6 лет назад. То ли на какой другой ресурс свинтили, то ли разочаровались в языке.

Просто повзрослели/поумнели (нужное подчеркнуть).

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

> Т.е. если человека поставить раком, за пол-года он будет уже матёрый спец по «Дям»

Другого метода нет для освоения языка?

А если как на ЛОРе каждый будет капризничать, конечно язык не продвинется!

В самом деле, что за идиоты, им тут вселенскую истину толкуют, а они про пирожки думают.

Еще один правоверный креститель подтянулся.

И ведь что смешно - себе же врут... Не писали ни строчки кода, а флейма уже на 100 комментов - ну не цирк? :)

На чем 100 строчек? На этом убогом by design языке, который авторами писался для самовыражения и забавы для?

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

> Мне, кстати, кажется, что оно, наоборот, дисциплинирует. Сначала обдумываем интерфейс, потом детали. Да и понять, что модуль делает, с выделенной интерфейсной частью проще.

Хотя кодеров, у которых скорость вылезания кода обгоняет скорость мышления, это раздражает.

+100

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

Интересно, вот обычно сначала спецификацию разрабатывают, а потом по спецификации делают проект. А в DigitalMars фичи добавляют, удаляют, перемещают каждый месяц.

Это единственный правильный способ написать нормальный проект. По спецификации пишут только в двух случаях:

  1. Нужно успокоить совковое начальство наличием плана.
  2. Нужно побольше отпилить.

P.S. если кому интересно куда я пропал из коммьюнити - *внезапно* понял что D - это идеальная иллюстрация Десятого правила Гринспена в действии. С каждым релизом обещают всё больше и больше фич... заимствованных из Лиспов. Но благодаря «человекочитаемому» синтаксису большинство из них оказываются реализованы как набор страшненьких костылей. Не таких страшненьких, как в C++, конечно.

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

ну ты же отрицаешь факты :) если все правильно, то где результаты?? где неглючная, фичастая версия Ди?? где инфраструктура?? А те идиоты, которые ратуют за «случайное» написание компиляторов - просто идиоты :)

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

И да, сложилось впечатление, то отечественное комьюнити Ди, это один naryl и есть :) Так что вашего отсутствия никто и не заметил :)

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

> Если верить вики, спеки делались 3 года

1977-1983 - 6 лет.

и компилятор 2,5 года

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

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