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

(плюс вызовы станартной библиотеки, конечно) (признак инстанцирования шаблона ("!") >встречается grep -r -e"\!" ./source | wc -l

2053 раза )

пожалуй, я погорячился

поточнее

grep -r -e"\!" ./source | grep -v -e"if"| grep -v -e"while" | grep -v -e"is " | wc -l

1359

всё равно, предлагаю выдыхать :)

постараюсь сформулировать, чуть попозже.

имхо, вся структура языка заточена на то, чтобы вынуждать человека указывать достаточно низкоуровневые подробности не тогда, когда это действительно нужно, а ПОСТОЯННО.

Rust грешит тем-же.

постараюсь сформулировать, чуть попозже.

Очень интересно было бы узнать вашу точку зрения. Без иронии.

имхо, вся структура языка заточена на то, чтобы вынуждать человека указывать достаточно низкоуровневые подробности не тогда, когда это действительно нужно, а ПОСТОЯННО.

Имхо, C++ для этого и создавался: в качестве мостка между очень низким уровнем (чистый C) и более-менее высоким (ООП из Simula, обобщенное программирование из ML). Отсюда и торчащие наружу низкоуровневые подробности.

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

Имхо, C++ для этого и создавался: в качестве мостка между очень низким уровнем (чистый C) и более-менее высоким (ООП

Да, конечно. В том-то и дело, что ниша более высокоуровневого средства, не скрывающего, тем не менее, низкоуровневые подробности, оказалась вакантна.

Вот в неё-то D и вписался.

Собственно, я это и пытаюсь сказать уже не первый раз

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

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

Вот в неё-то D и вписался.

Ага, с консервативным GC на перевес. Вот Rust, да, может вписаться. Но это только время покажет.

Ага, с консервативным GC на перевес.

Да ладно. --gc-sections, например.

Вот Rust, да, может вписаться.

не может. у него другая парадигма.

Вот в неё-то D и вписался.

Ну вот это-то как раз и сомнительно. Больше похоже на то, что D — это инструмент класса Java/C#, но для нейтива. Но вот нужен ли такой инструмент на нейтиве вообще — это уже вопрос. И нужен ли он в ситуации, когда для той же Java/C# инфраструктура на порядки лучше — это еще больший вопрос.

Впрочем, мы ходим кругами.

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

Пара ключевых отличий D-шных шаблонов от плюсовых на данный момент — это static if в D и необходимость вписывать typename и template в шаблонных конструкциях в C++. Можно ли эти вещи считать серьезным преимуществом D-шных шаблонов над C++ными для меня не очевидно.

Ну вот это-то как раз и сомнительно. Больше похоже на то, что D — это инструмент класса Java/C#, но для нейтива.

БИНГО!!!

нужен ли такой инструмент на нейтиве вообще — это уже вопрос.

не вопрос. нужен.

А принципиально ведь тоже самое.

Да ну? Чтобы усомниться,достаточно пролистать (Шаблоны C++: справочник разработчика http://www.books.ru/books/shablony-c-spravochnik-razrabotchika-122949/?show=1) и PhilippeSigaud/D-templates-tutorial https://github.com/PhilippeSigaud/D-templates-tutorial.git

Да, кончно, с учётом устарелости Джосатиса, и тем не менее

БИНГО!!!

Дык это бинго для тех, кто ищет Java/C# для нейтива, а не для тех, кому нужен более современный C++, лишенный заморочек совместимости с C.

Да ну? Чтобы усомниться,достаточно пролистать...

Ну да. Берем пример из D-templates-tutorial:

struct Tree(Type) {
    Type value;
    Tree[] children;

    size_t size() {
        size_t s = 1;
        foreach(child; children)
            s += child.size();
        return s;
    }

    bool isLeaf() @property {
        return children.length == 0;
    }
}

using namespace std;
template< typename Type > struct Tree {
  Type value;
  vector< shared_ptr< Tree > > children;

  size_t size() const {
      size_t s = 1;
      for( const auto & child : children)
          s += child->size();
      return s;
  }

  bool isLeaf() const {
      return children.size() == 0;
  }
};

Допустим, что можем использовать shared_ptr

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

Кстати да, если в описании указать vector<Tree> children, то так же успешно скомпилируется и будет работать.

слёту нет, надо придумать или поискать общеизвестный код. думаю, подойдёт абсолютно любой пример :)

Мне тоже интересно. С тем, что D-шные шаблоны поприятнее спорить не буду, но кардинальной разницы не замечаю. Причём, если смотреть вот сюда, то местами кажется, что в С++ даже получше, пусть и незначительно. Например, если говорить о template typedefs.

Общее впечатление такое - да, покрасивее, но могли бы лучше.

В целом да шаблоны D и C++ очень близки. Но как минимум static if уже сильно улучшает и упрощает местами код. Кроме того шаблоны в D в целом более мощная концепция так отображают произвольный кусок кода, а не только классы или функции в C++, что позволяет подмешивать код шаблонов (mixins). Кроме того в D есть достаточно развитый compile-time reflection, что тоже упрощает программирование на шаблонах. А для кардинальной разницы (если брать статически типизированные языки которые более-менее на слуху) нужно смотреть на шаблоны Nim http://nim-lang.org/docs/manual.html#templates там по моему использован самый правильный подход - шаблоны это «легкий» вариант макросов.

По стандарту кажется не должно.

Но как минимум static if уже сильно улучшает и упрощает местами код.

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

нужно смотреть на шаблоны Nim

Ним местами интересен, но производит впечатления хаотичной кучи фич. Хотя может и вырастет до чего-то толкового.

По стандарту кажется не должно.

Почему?

Но как минимум static if уже сильно улучшает и упрощает местами код.

Это если им не злоупотребляют :(

Кста, аналог в виде constexpr_if уже собираются сделать в C++17, вроде как предложение получило предварительное одобрение и пошло в группу для подготовки к включению в стандарт.

UB http://cpp14.centaur.ath.cx/res.on.functions.html#p2.5

Скажем такой код:

#include <deque>

struct Test
{
    std::deque<Test> childs;
};

int main()
{
    Test tst;
}

VC не переваривает (gcc и clang нормально кушают), но если заменить на vector то все уже работает. В общем работать не обязано по стандарту. 

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

Это да неосиляторы С++ любят гиперболы :) Хотя если смотреть на старый стандарт + несовершенство, недотягивание до стандарта, до недавних пор, компиляторов, то да местами прямо кошмар получался, особенно на фоне языков с более прямым макропрограммированием.

Ним местами интересен, но производит впечатления хаотичной кучи фич. Хотя может и вырастет до чего-то толкового.

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

Вообще ним вполне может и выстрелить, своей корявостью и «хаотичной кучи фич» на C++ сильно походит :)

Интересные вещи, спасибо.

Не зря, значит, я изначально с shared_ptr вариант написал.

Это если им не злоупотребляют :(

Альтернатива в виде многоэтажных рекурсивных шаблонов не лучше :(

Кста, аналог в виде constexpr_if уже собираются сделать в C++17

Неплохо бы.

Неплохо бы.

Я тоже так понял, что соответствующее предложение http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0128r0.html поддержали: https://isocpp.org/blog/2015/11/kona-standards-meeting-trip-report

Мне тоже интересно. С тем, что D-шные шаблоны поприятнее спорить не буду, но кардинальной разницы не замечаю. Причём, если смотреть вот сюда, то местами кажется, что в С++ даже получше, пусть и незначительно. Например, если говорить о template typedefs.

Общее впечатление такое - да, покрасивее, но могли бы лучше.

Интересная статья Уолтера Брайта про шаблоны в D «Templates Revisited» http://dlang.org/templates-revisited.html

Даже простая замена синтаксиса шаблонов < > на ( ) и ! дает очень много.

«Выражения

a<b,c>d; a<b<c>>d;

синтаксически неоднозначные, и для программиста, и для компилятора. Если вы видите a<b,c>d; в незнакомом коде, вам придется продираться через большое количество определений и .h файлов, чтобы понять шаблоны это или нет. Сколько сил тратится программистами, разработчиками компиляторов и разработчиками стандартов языков чтобы справиться с этим?

Должен быть более правильный путь. D решает эту проблему, воспользовавшись тем фактом, что оператор ! не используется как бинарный оператор, так что заменив:

a<b,c>

на

a!(b,c)

мы избавляемся от синтаксической неоднозначности. Это облегчает парсинг, упрощает генерацию понятных сообщений об ошибказ, и при просмотре кода легко заметить, что данный фрагмент кода - шаблон.»

Неоднозначности на порядок затрудняют компилятору работу. Для того, чтобы отличить использование шаблонов от прочих выражений компилятору нужно знать, что означают a, b, c, d (определенные где-то в недрах .h файлов).

Если вы видите a<b,c>d; в незнакомом коде

То вам крайне повезло, т.к. найти такую запись, и с таким форматированием, в реальном коде практически нереально.

Если вы видите a<b,c>d; в незнакомом коде, вам придется продираться через большое количество определений и .h файлов, чтобы понять шаблоны это или нет. Сколько сил тратится программистами, разработчиками компиляторов и разработчиками стандартов языков чтобы справиться с этим?

Придумали себе проблему и героически решаем. Если кто-то когда-то тратил «силы» на разбор такого выражения, пусть отметится тут. И заодно расскажет, кто был тем мудаком, кто пищет код без пробелов и внятных идентификаторов.

Интересные вещи, спасибо.

Это надо вызубрить и запомнить на зубок, как и всё в цепепе, чтобы хоть как-то корябкать на нём :-)

Хватит лыбиться, код покажите. За это время даже на C можно было что-нибудь накарябать.

Хехе, цепепешники в очередной раз будут несколько лет ждать, скрестив пальчики, пока очередная конструкция появится в их любимом язычке :-) Бгг :-)

И заодно расскажет, кто был тем мудаком, кто пищет код без пробелов и внятных идентификаторов.

И заодно пусть расскажет, кто был тем несчастным, кто пишет компилятор для языка с такой уродской семантикой, сильно зависящей от контекста :-) Бедные, бедные :-)

За это время даже на C можно было что-нибудь накарябать.

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

Анонимный лиспер, который в сраче D vs C++ агитирует за переход на чистый C настолько упорот, что позор ему вряд ли страшен.

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

Это ты о ком сейчас? :-) А то вот такой код я бы не показывал даже за бабки :-)

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

Мне не ведомо как можно публиковать разное фуфло :-)

настолько упорот

Это всё цепепе виноват :-)

Пофиг с чего вы упоролись до полной неадекватности. Раз вы настаиваете на использовании чистого C вместо D и C++, то извольте показать, как это будет выглядеть. А то ведь код писать — это не на форумах звиздеть.

А то ведь код писать — это не на форумах звиздеть.

Зачем же так однобоко? :-) Код не только можно писать, но и читать. :-) И очень часто, что второе намного сложнее первого. Особенно, если это цепепе или какой-нибудь пёрл :-)

Вы тут неделю убеждаете всех, что вместо D и C++ нужно писать на чистом C. При этом сами написать на C даже простую программу не можете. Не удивительно, что C++ный код прочесть вам не дано.

Это ты о ком сейчас? :-) А то вот такой код я бы не показывал даже за бабки :-)

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

Код не только можно писать, но и читать. :-)

С кодом много чего можно делать, но писать ты его не способен.

Вы тут неделю убеждаете всех, что вместо D и C++ нужно писать на чистом C. При этом сами написать на C даже простую программу не можете. Не удивительно, что C++ный код прочесть вам не дано.

Ну хорошо, убедил :-)

PS. Не люблю стиль, когда внутренности скобок отделяются от самих скобок пробелами :-) Сразу наводит на подозрение, что автор испытывает проблемы с чтением кода :-)

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

Это не флуд, это просто просто отчаянная попытка обратить внимание на классику :-)

С кодом много чего можно делать,

Лучше по-чаще его выбрасывать :-)

но писать ты его не способен.

Способен!!1

А твой код действительно паршив.

Он просто великолепен. Показывает весь идиотизм пихания функционального подхода туда, где он не нужен.

Анонимный лиспер, который в сраче D vs C++ агитирует за переход на чистый C

Вообще-то, тема про новый компилятор D. И что ты тут со своим C++ устраиваешь «срач» вызывает недоумение.

Ну срач С++ vs D вполне логичен, а вот приплетать сюда С, который совсем для других задач - глупо.

Вообще-то, тема про новый компилятор D. И что ты тут со своим C++ устраиваешь «срач» вызывает недоумение.

Заходим на http://dlang.org/overview.html, и видим, что кол-во упоминаний C++ просто зашкаливает. Ну и если авторам такое можно, то почему нельзя остальным.

Ну срач С++ vs D вполне логичен, а вот приплетать сюда С, который совсем для других задач - глупо.

И с какую-такую задачу, которую можно решить на C++, нельзя решить на C? Лол.

И с какую-такую задачу, которую можно решить на C++, нельзя решить на C? Лол.

Тут уже одному С-шнику предложили переписать на С десять строчек на D. Результата до сих пор нет.

Написать то все можно, но нужно ли? Можно и на чистом ассемблере написать все, что угодно, но какой от этого профит?

Написать то все можно, но нужно ли?

Какого хрена тогда на твоём компе большинство софта написано на C? Нужно ли?

Можно и на чистом ассемблере написать все, что угодно, но какой от этого профит?

Можно и на чистом ассемблере, если для конкретной железяки. А профит от C как раз такой, что код на нём самый портабельный, чем все эти бусты вместе взятые.

Какого хрена тогда на твоём компе большинство софта написано на C?

Если говорить конкретно про мой, то еще не мешало бы убедиться, что большинство софта написано на C. Может под Linux-ами без KDE это и так, а вот под оффтопиком ситуация не так однозначно, т.к. в самой винде C++ используется активно, в том числе и для драйверов.

Из того, чем приходится пользоваться постоянно: три браузера (Firefox, Chrome, Opera) — С++, компиляторы (MinGW-w64 и VC++) — C++, Adobe Lightroom и Acrobat Reader — C++, Vim — С, виртуальная машина Ruby — С. Не знаю на чем написаны IrfanView и AIMP2.

Как бы доминирования C не наблюдается.

А профит от C как раз такой, что код на нём самый портабельный

Да, есть такое дело. Только не нужно умалчивать цену такой портабельности. Линусу хорошо, у него нет бюджета на разработку Linux-а, а вот если у программного проекта есть и бюджет, и сроки, то низкий уровень C и большее количество телодвижений для достижения сравнимого результата, скорее всего, будут перевешивать плюсы от высокой портабельности.

А профит от C как раз такой, что код на нём самый портабельный

Эта «портабельность» заключается в тоннах препроцессорных директив под каждую различную платформу и даже компилятор. Посмотри код zlib - это не портабельность, это ее противоположность.