LINUX.ORG.RU

Вышла первая версия компилятора D, написанная на D

 


3

6

Сегодня состоялся очень важный релиз компилятора языка D — DMD 2.069.0. До настоящего момента компилятор D был написан на С++, однако новая версия теперь написана на самом D. Процесс конвертации исходного кода с С++ на D занял значительный промежуток времени, однако позволил многократно упростить поддержку компилятора.

Значительным улучшениям подверглась стандартная библиотека Phobos. Теперь ещё больше функций в ней были рэнджефицированы (ranges — концепция, позволяющая упростить доступ и переборку элементов структур и классов).

DMD теперь поддерживает формат mscoff, используемый в библиотеках VS2015.

Активно ведутся работы над поддержкой мобильных платформ. В настоящий момент сообщается, что рантайм языка и библиотека Phobos проходят практически все тесты на устройствах Android. О полноценной поддержке разработки под iOS пока говорить нельзя, однако благодаря усилиям проекта LDC-iphone несложные приложения на D под iOS писать можно уже сегодня.

Для пользователей Linux выложена первая пробная версия компилятора Calypso, позволяющая в D использовать практически все существующие С++-библиотеки, даже такие большие и сложные, как Qt5 и Ogre3D.

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

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

Противники и сторонники сборщика мусора (GC) могут ознакомиться с дискуссией о том, что безопасную сборку мусора невозможно реализовать на базе исключительно библиотечных функций.

Новая версия сервера DCD, реализующая автодополнения исходного кода, также готова к использованию с новой версией DMD.

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

★★

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

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

Реализация будет выглядеть точно так же, как и без .di файла.

Понятно, спасибо.

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

(1) понимать, зачем это вообще нужно и что за зверь dangling pointer (2)

Дык, целевая аудитория языка - это, в немалой степени, программисты на С/С++. А у них проблем с пониманием таких вещей быть не должно.

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

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

Да ради бога, пусть будут инклуды, почему модулей-то нет?

Дык, делают/думают. Когда-то будут.

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

Тем не менее, если вы так любите C, то что вы делаете в теме про D? Это язык ничуть не проще C++.

Он влезает в любую тему, если находит там упоминание С++, и начинает бредить. Лучше не обращай внимание.

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

НО! любое развитие C++, отягчено проклятием шаблонов.

Так их тоже «развивают». Те же концепты, например. С ними и читать и писать шаблоны станет полегче.

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

почему это «хакеризм». пояснения требуются?

Да, пожалуйста. Особенно про первый пример.

Во втором случае, кстати, лайфтам указывать не обязательно.

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

Ты перескакиваешь с одного на другое. То у тебя «совместимость не нужна», то «D ничего и не ломал (почти)».

А всё вместе собрать - интеллекта нехватает? Тогда увы, ты точно ошибся трэдом.
1. «Совместимость не нужна» - это правда, ибо Ди молод и не имеет такого громадного говнонаследия как С++. Чем я тут не прав?
2. «D ничего и не ломал» и это ТОЖЕ ПРАВДА, ибо язык стабилизировался и всхлипы задротов, никогда не касавшихся Ди уже поднадоели. НА ДИ МОЖНО ПИСАТЬ, больше нет никаких «breaking changes»! Это главное, что сегодня пора усвоить.

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

НА ДИ МОЖНО ПИСАТЬ, больше нет никаких «breaking changes»! Это главное, что сегодня пора усвоить.

На C можно писать. Это главное, что сегодня пора усвоить :-)

anonymous
()
Ответ на: Что называется с разворота ногой в е от anonymous

И что забавно, у них на главной висит этот ужас:

import std.stdio;
import std.array;
import std.algorithm;

void main()
{
    stdin
        .byLine(KeepTerminator.yes)
        .map!(a => a.idup)
        .array
        .sort
        .copy(
            stdout.lockingTextWriter());
}

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

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

Эти люди не собираются тащить с собой то, что можно не тащить. Иначе получится как в плюсах. Вот вторых плюсов точно никому не нужно. Замена .sort на .sort() никого не убьет, хотя да, повода для срача даст знатно - тут же не важна суть, важно что дескать «ногой по ебалу» - звучит-то как круто. Ну и deprecated не означает, что не скомпилируется, работать будет еще какое-то время, если так нужно, срок удаления из языка пока не обозначен. В общем нормальный процесс исправления неоптимальных вещей. Вместо попыток через одно место натянуть, как это делается в некоторых языках.

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

Эти люди не собираются тащить с собой то, что можно не тащить. Иначе получится как в плюсах.

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

В общем нормальный процесс исправления неоптимальных вещей

Это нормальный процесс для альфы/беты. Ну или для новой мажорной версии. А когда в минорных ломают старый код - это ненормально, это у%банство и недальновидность авторов.

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

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

В общем да, поскольку на D за 15 лет не написано и доли процента от того, что за 30 лет было написано на C++, можно себе позволить такой «нормальный процесс исправления неоптимальных вещей».

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

Вот представь, что стандарт С бы регулярно в несколько месяцев что-то ломал. И это поддерживалось бы в минорных версиях GCC. Да дистрибутивы Linux бы полегли просто из-за невозможности собрать большую часть пакетов. Не говоря уж про ломку уровня D1/D2. Потому язык с подходом как у D обречен быть на задворках. А Java, C++, С и пр. языки будут нужны еще долго, пока им на смену не придут изначально хорошо продуманные новые языки. Чьи авторы не будут считать свой язык своей личной песочницей с песочными замками.

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

Кстати, не понятно, зачем вот здесь map!(a => a.idup).

Кто-нибудь из D-шников может пояснить зачем в языке с GC явно вызывать дуплицирование объекта?

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

Ну так надо добавлять, что лично для меня это не приемлимо. А я когда столкнулся с этим просто добавил в пару мест скобки и не вспомнил бы, если бы не ваш пост. Лично для меня это приемлимо и никаких сложностей не вызывало и не вызывает.

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

Ну в общем-то вы-то должны четко понимать, что D 10 лет назад это другой язык, чем сегодня. Так зачем душой кривить? У меня вопрос лично к вам - если вам не нравится D, зачем вы его постоянно обсуждаете? Вот мне не интересен язык X, так я его не обсуждаю. Вы хотите, чтобы вас убедили в том, что D нужно использовать?

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

Да никто ничего не ломает. Deprecated это предупреждение компилятора. Ломка D1/D2 это был безусловно очень рискованный шаг и аукается до сих пор в виде слухов, что все ломается регулярно. Ничего не ломается, язык более чем годен для продакшена, хотя по тулзам и либам не так богат как тот же C++.

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

А я когда столкнулся с этим просто добавил в пару мест скобки

А теперь представь, что твой код кому-то нужен и его положили в дистрибутив. И чтоб собрать его нужен новый компилятор. Обновляем компилятор - ломаются все остальные пакеты, чьи авторы не успели/не захотели обновляться до самой свежей версии компилятора. Причем эта проблема есть и в С/C++. Например то же ключевое слово auto изменило поведение. Но как делают нормальные люди - эти изменения делаются в новом мажорном стандарте, а в компилятор добавляют параметр -std=c99, -std=c++11 etc. И старый код прекрасно собирается новым компилятором, а новый код пишется под один единый неизменяемый стандарт, а не десятки, а то и сотни минорных. Вот это и есть стабильность, которую можно обеспечить даже ломая старое. Но в D о таком не слышали.

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

Да никто ничего не ломает. Deprecated это предупреждение компилятора

Ты в табличке точно все колонки увидел?

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

Здесь вообще ГЦ не причем, тут нет ничего сложного, это банальная операция копирования буфера ввода-вывода. Вы же не хотите, чтобы у вас вывелась в консоль n раз последняя считаная строка, где n это общее количество считанных строк?

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

У меня вопрос лично к вам - если вам не нравится D, зачем вы его постоянно обсуждаете?

Надеюсь, что меня переубедят адекватной аргументацией. Пока ее не видно, только «D уже стабилен» и «D нестабилен, но так и надо».

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

это банальная операция копирования буфера ввода-вывода. Вы же не хотите, чтобы у вас вывелась в консоль n раз последняя считаная строка, где n это общее количество считанных строк?

А почему не было использован byLineCopy?

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

тулзам и либам не так богат как тот же C++

Тулзы и либы цепепе ужасного качества и полны глюков :-)

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

Тулзы и либы цепепе ужасного качества и полны глюков :-)

Твой тупой троллинг реально задолбал. Будь креативней.

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

Вы хотите, чтобы вам «продали» язык? Любая продажа начинается с выяснения потребностей клиента. Вы никогда не продадите Порш Кайен аборигену в Африке. И не потому, что Порш - гавно, а бусы - это круто. А потому, что потребности у него нет в машине вообще. Поэтому аргументированно «продать» вам язык не сможет никто. Ибо вы - анонимус и вообще не ясно, чего вы хотите пожизни. Зато «затроллить» любого, кто попытается вам его «продать» вы сможете легко. Думаю, нет смысла дальше продолжать? Ну и сразу же добавлю на всякий случай, что «продавать» D я никому не буду. Не хотите использовать - не используйте. В моей ситуации он подходит лучше чем С и C++, я им пользуюсь.

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

Ну в общем-то вы-то должны четко понимать, что D 10 лет назад это другой язык, чем сегодня.

Не-а. Язык — это не только набор каких-то фич с определенным синтаксисом и некоторой стандартной библиотекой. Язык программирования — это целая экосистема.

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

У меня вопрос лично к вам - если вам не нравится D, зачем вы его постоянно обсуждаете?

Язык D1 мне очень нравился. Начав работы над D2 авторы языка, имхо, убили надежды на попадание языка в мейнстрим в обозримом будущем. Поэтому D2 мне не нравится не смотря на некоторые интересные фичи, которые в нем присутствуют. Тем мне менее, наблюдать за развитием интересно. Скажем, смотреть, как развивается Java не интересно от слова совсем, а вот как развивается D — интересно :)

Вы хотите, чтобы вас убедили в том, что D нужно использовать?

Нет. У меня есть некий набор соображений, исходя из которых краем глаза смотрю на языки, которые потенциально могли бы заменить C++. Поэтому пытаюсь оценивать, нужно ли вообще кому-то использовать D. Если да, то кому и в каких условиях.

Пока получается, что мало кто использует D для разработки чего-то действительно серьезного. Но даже если и используют, то в условиях эдаких самодостаточных маленьких групп: собрались два-три человека с общими интересами и выбрали D, т.к. от C++ или от Java их тошнит, и пилят какой-то мелкий софт в своем узком кругу.

Получается, что кодовая база практически вся своя и не сильно большая, изменения в компиляторе не страшны, т.к. либо есть возможность все быстренько подправить, либо же вообще можно сидеть годами на D1. Людей новых в проект вводить приходится не часто, если вообще приходится. Сторонние библиотеки редкость, с платформы на платформу не нужно портировать, с другими системами интегрироваться и т.д.

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

По моему byLineCopy появился позднее, чем был написан этот пример, но не уверен.

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

Здесь вообще ГЦ не причем, тут нет ничего сложного, это банальная операция копирования буфера ввода-вывода.

Просто в языках с GC более привычно видеть что-то вроде:

file.each_line {|l| my_storage << l }
и расчитывать на то, что l для каждой строки создается заново, поэтому ее можно сохранить в своем собственном векторе не думая о том, ее содержимое будет перезаписано следующей прочитанной строкой.

Тут же получается, что byLine использует буфер, ссылку на который отдает в map. Но при этом говорит — это буфер для чтения, если ты сохранишь ссылку на него, то потом прочтешь лишь самое последнее значение. Какой-то чисто C-шный подход в языке гораздо более высокого уровня.

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

Вы хотите, чтобы вам «продали» язык?

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

Не хотите использовать - не используйте.

Хотел бы, и вероятно и буду в связке с тем же С++, но когда будет действительно стабильная версия D. Собс-но потому на эту тему и разговариваю.

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

Понятно зачем нужное. Во первых, для новых языков (пусть это не случай D) это своего рода проверка на готовность. Во вторых, разработчики на D, особенно в будущем, не обязательно С++ знать будут, а так для них проще развивать язык. Ну и в третьих компиляторы множества языков написаны сами на себе и никого это не беспокоит.

кросс-компимляция расслабила людей;)

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

Получается, что кодовая база практически вся своя и не сильно большая, изменения в компиляторе не страшны, т.к. либо есть возможность все быстренько подправить, либо же вообще можно сидеть годами на D1. Людей новых в проект вводить приходится не часто, если вообще приходится. Сторонние библиотеки редкость, с платформы на платформу не нужно портировать, с другими системами интегрироваться и т.д.

В моем случае кодовая база действительно небольшая, но используется много зависимостей, я бы даже сказал очень много, иногда сталкиваюсь с проблемой, что dub не может подобрать корректное сочетание зависимостей, приходится явно указывать версии пакетов. Изменения в компиляторе последние года вообще не вызывают проблем. Более того, каждая версия содержит улучшения, функционал улучшается, реально есть желание перейти на свежую версию, потому что там больше плюшек. Что в компиляторе реальная проблема по мне, как реальному пользователю языка, так это отставание ldc/gdc от dmd по версии фронтенда, потому что я сейчас до сих пор сижу на 2.067.1, хотя вышел 2.069, потому что в release ldc код в несколько раз эффективнее на моих задачах. Насчет ввода людей - у нас как минимум половина кто пишет код это научные сотрудники скажем, не программисты. Да и я себя скорее к первым отношу, чем ко вторым. Так там код такой порой пишут, что «закачаешься». И мыслят они совсем другими категориями. И я просто не представляю как их пересадить на тот же rust. Проще будет застрелиться. А вот на D я их переведу при необходимости. Это на заметку руководителям и начальникам. Сторонние библиотеки не редкость, сишных зависимостей тоже хватает, плюсовых нет(пока). С платформы на платформу перейти элементарно - проблема возникает в сишных зависимостях, как не странно. (напоминаю что это конкретный случай). Интеграция с другими системами есть через сокеты, проблем нет вообще. Layout дишных и плюсовых структур данных совпадает, поэтому вообще проблем нет, за исключением того, что нужно синхронизировать .h и .d файлы с описанием этих структур данных. И это можно автоматизировать, но пока не вижу смысла, изменения не так часты и в основном добавления.

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

Интеграция с другими системами есть через сокеты, проблем нет вообще.

Да это самый идеальный случай интеграции. А вот когда всплывает REST, Protobuf, Thrift или, прасти хосподи, SOAP или ASN.1 какой-нибудь...

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

Какой-то чисто C-шный подход в языке гораздо более высокого уровня.

Есть такое, согласен. Это следствие си-подобности, люди сделали как было проще, со временем заменят на более идиоматический подход. Та же byLineCopy появилась как раз на замену этой конструкции и является более эффективной за счет кеширования и пример кода там приведен более актуальный, как анонимусам хотелось бы - используются и byLineCopy() и sort().

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

Вот смотришь на такое:

auto byLineCopy(Terminator, Char)(
  KeepTerminator keepTerminator = KeepTerminator.no,
  Terminator terminator = '\x0a'
)
if (isScalarType!Terminator);

auto byLineCopy(Terminator, Char)(
  KeepTerminator keepTerminator,
  Terminator terminator
)
if (is(Unqual!(ElementEncodingType!Terminator) == Unqual!Char));
и думаешь: конечно же, без привычки и с поверхностным знанием языка сложно судить о простоте примеров, но выглядит это так, что D2, может и проще C++. Не не сказать чтобы уж сильно проще.

Такое впечатление, что на C++14 записывалось бы это похожим образом, разве что синтаксический оверхед был бы чуть повыше.

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

Такое впечатление, что на C++14 записывалось бы это похожим образом, разве что синтаксический оверхед был бы чуть повыше.

Выкинуть все эти нерадивые поделия и писать на C :-)

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

if (isScalarType!Terminator);

В концептах из С++17 будет так:

requires is_scalar<Terminator>

Что выглядит куда логичнее, чем снова и снова переиспользовать ключевое слово if.

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

Выкинуть все эти нерадивые поделия и писать на C :-)

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

import std.algorithm, std.array, std.stdio;
// Print sorted lines of a file.
void main()
{
    auto sortedLines = File("file.txt")   // Open for reading
                       .byLineCopy()      // Read persistent lines
                       .array()           // into an array
                       .sort();           // then sort them
    foreach (line; sortedLines)
        writeln(line);
}
Лишь после этого можно будет продолжить разговор о вашей «точке зрения».

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

Еще не понятно, войдут ли концепты в C++17. Пока из оформят в виде TS для ознакомления и экспериментов (первая реализация этого TS ожидается в GCC 6 в 2016-ом году). В C++14 этот код, полагаю, можно будет переписать с std::enable_if. Получится чуть многословнее, но принцип будет точно такой же.

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

В C++14 этот код, полагаю, можно будет переписать с std::enable_if.

И в С++11 тоже.

первая реализация этого TS ожидается в GCC 6 в 2016-ом

Еще летом добавили:

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=56c12fd4ba064759724236ad8962326...

Вроде как будет в 5.3, достаточно будет указать -std=c++1z при сборке.

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

И в С++11 тоже.

Перепутал с std::enable_if_t из C++14, кроме того, в C++14 вроде как разрешается auto в качестве типа возвращемого значения функции/метода (в C++11 нужно писать auto f() -> return_type).

Еще летом добавили

Я исхожу из того, что люди написали в своих впечатлениях после крайнего заседания комитета в октябре 2015-го. Вроде как к концептам появились вопросы.

https://botondballo.wordpress.com/2015/11/09/trip-report-c-standards-meeting-... https://isocpp.org/blog/2015/11/kona-standards-meeting-trip-report

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

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

аналог вот этого кода на чистом C

Как-то так:

#include <stdio.h>
#include <string.h>

int line_cmp( const char** a, const char** b ) {
    return strcmp( *a, *b );
}

int main() {
    char  buf   [ 1024 * 1024 ];
    char* lines [ 4096 ];
    int   count = 0;
    int   len   = fread( buf, 1, sizeof( buf ), stdin );

    buf[ len ] = 0;
    for( char* t = strtok( buf, "\n" ) ; t ; t = strtok( 0, "\n" ) )
        lines[ count++ ] = t;

    qsort( lines, count, sizeof(char*), line_cmp );

    for( int i = 0 ; i < count ; ++i )
        puts( lines[ i ] );

    return 0;
}

Если не заморачиваться на malloc/realloc при вычитке файла и проверки. И замену strtok на strchr для оптимизации. Что в принципе тоже не особо долго пишется. Но и так и так этот код будет гораздо быстрее варианта на D.

// Другой анонимус, а не идиот со смайликами.

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

В общем-то совсем код не аналогичный по функционалу и сравнение некорректное. А если строк в файле будет больше 4096? Вы, кстати, пробовали запустить этот код? Работает реально быстрее чем вариант на D, но как в анекдоте - такая херня получается. И сравните объем кода. А если задача не такая тривиальная?

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

В общем-то совсем код не аналогичный по функционалу и сравнение некорректное. А если строк в файле будет больше 4096?

Я же написал - malloc/realloc + проверки. Со зрением плохо? Кроме того да, не аналогичный, т.к. в С слишком скудная стандартная библиотека, а человек поставил задачу «на чистрм С». А библиотечные вызовы функций на С тут могут быть еще короче чем решение на D.

Вы, кстати, пробовали запустить этот код?

Да.

Работает реально быстрее чем вариант на D, но как в анекдоте - такая херня получается.

Херня это копировать данные в отдельные строки. Если уж решился выжрать весь файл в память - делай это экономно и эффективно. Иначе «такая херня получается».

И сравните объем кода

На ruby пишется в одну строку. D не нужен.

А если задача не такая тривиальная?

Показать примеры действительно больших проектов на С? Которых на D нет и не будет в ближайшее время? Или сам найдешь?

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

Показать примеры действительно больших проектов на С?

Идиот со смайлами уже показывал - PostgreSQL :-) Но упоротые любители цепепе и Ди-Лангуаге его не слушают, он же идиот :-)

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

Ради интереса портировал ваш код на D:

import core.stdc.stdio;
import core.stdc.stdlib;
import core.stdc.string;

extern(C) int line_cmp( const void* a, const void* b ) {
    auto aa = cast(char**) a;
    auto bb = cast(char**) b;
    return strcmp( *aa, *bb );
}

int main() {
    char  buf   [ 1024 * 1024 ];
    char* lines [ 4096 ];
    int   count = 0;
    long  len   = fread( buf.ptr, 1, buf.sizeof, stdin );

    buf[ len ] = 0;
    for( char* t = strtok( buf.ptr, "\n" ) ; t ; t = strtok( null, "\n" ) )
        lines[ count++ ] = t;

    qsort( lines.ptr, count, (char*).sizeof, &line_cmp );

    for( int i = 0 ; i < count ; ++i )
        puts( lines[ i ] );

    return 0;
}
Ничто не мешает вам писать на D в любимом сишном стиле. Скорость, подозреваю 1 к 1 (ну это я уже не буду проверять). При этом выловлен 1 баг в компайл-тайм
long  len   = fread( buf.ptr, 1, buf.sizeof, stdin );
С не выловил несоответствие int и long, в отличие от D. Конечно, файлы больше чем 4Гб это редкость в обычной жизни и в память их может и не читают, но факт есть факт. И второй баг выловлен в рантайме - когда размер файла больше 4096 сишная версия сыпет в консоль мусор (хотя и делает это быстро, ага). Дишная версия падает с сообщением
core.exception.RangeError@main2.d(17): Range violation
Даже думать не надо где искать ошибку. В реальных условиях, когда мозг загружен по самое нехочу, какой бы умный ты не был, тратить время где его можно не тратить это всегда хорошо. Спасибо за хороший пример, где D лучше C. Насчет же C - это хороший язык и есть вещи, где он лучше всех других языков. Но не в данном случае, явно. Руби, кстати, это тоже касается.

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

Ничто не мешает вам писать на D в любимом сишном стиле.

Где-то кто-то нечто подобное уже говорил :-) По-моему, дедушка, который придумал цепепе :-)

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