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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

«D ничего и не ломал» и это ТОЖЕ ПРАВДА, ибо язык стабилизировался

Данный список говорит, что не только ломал, но уже и готовы новые поломки:

http://dlang.org/deprecate

Что называется с разворота ногой в е

бало

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

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. Т.е. первый же пример, который они показывают всем, - уже устарел, обругивается компилятором и будет сломан. И эти люди что-то говорят про стабильность.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

file.each_line {|l| my_storage << l }

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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));

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

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

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

if (isScalarType!Terminator);

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

requires is_scalar<Terminator>

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

Выкинуть все эти нерадивые поделия и писать на 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);
}

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

В 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 при сборке.

И в С++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

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

аналог вот этого кода на чистом 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.

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

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

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

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

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

Да.

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

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

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

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

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

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

Иди сюда[/c] :-)

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

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

Ради интереса портировал ваш код на 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;
}

long  len   = fread( buf.ptr, 1, buf.sizeof, stdin );

core.exception.RangeError@main2.d(17): Range violation

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

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

А вот и идиот, давай свой вариант.