Компилятор языка D будет переписан с С++ на D

А на чем он должен быть написан, на D?

Можно книжку Александреску полистать, для ознакомления.

Для коммерческих проектов пока, ИМХО, негоден.

Почему нет?

Т.е. язык крут, но его время пока не пришло? Судя по вики - он появился ещё в 1999 году ... 14 лет ... Ок. Ждем ещё. Но чет мне кажется что скорее нишу займут какие-нибудь другие языки.

Угу, и получится язык, заточенный под написание этого самого языка :D

Из того что нет в С++ GC, строки, нормальная модульность, отсутствие необходимости работы с указателями (адресная арифметика), нормальный rtti,...

• В C++ есть некоторый аналог GC - умные указатели, точно так же объект будет уничтожен, когда счётчик ссылок на него станет равным нулю, и нет нужды вручную делать delete/retain/release. В большем необходимости нет, хотя бы потому что C++ отлично связывается с языками типа javascript, QML или Lua, которым плюсовый рантайм может дать не только CG, но и изоляцию + инструменты отладки.
• экспериментальная поддержка модульности есть в clang, а сложность тут в доработке остальных компиляторов, тулзов типа doxygen и существующих API, использующих #include и определяемые перед #include макросы. Это лучше, чем «нормальная» модульность в D, всегда требующая биндингов библиотек вместо плавного перехода.
• В C++ нужна адресная арифметика? А если и так, в C# она тоже есть - просто выкинута куда-то в глубь, где работает написанный на C++ движок. Точно так же адресная арифметика выкидывается вглубь программы и в C++.
• rtti есть в библиотеках

В D есть более прикольные штуки.

Вот несколько примеров.

«uniform syntax» - то есть если у нас есть функция f(int x) му можем её вызвать как 2.f() - что капиатально упрощает работу с шаблонами. Работает и для своих типов и функций.

«alias this» - можно объявить переменную-член класса (или структуры) таким алиасом, после чего вызовы, которые не может отресолвить сам объекты компилятор будет пытаться отресолвить через эту переменную. Получаем аналог множественного наследования без его недостатков.

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

thread-local глобальные переменные, встроенные в язык

immutable. Здесь же - то, что const рекурсивен. В результате для многопоточного софта писать проще

erlang-like посылка/приём сообщений потокам.

контракты у объектов/структур и функций

В общем, сам язык очень интересен.

Надо бы ещё про ranges написать, но это лучше послать к статье Александреску.

набирающего популярность языка D

толсто =)

как показывает статистика, язык все больше теряет последователей на фоне таких замечательных высокопроизводительных ЯП как Go и Rust.

как показывает статистика, язык все больше теряет последователей на фоне таких замечательных высокопроизводительных ЯП как Go и Rust.

А вот и дети-фантазеры подтянулись.

Thread-local есть в C++. Потокобезопасная посылка и приём сообщений есть в Qt, да и вообще реализуемо в библиотеках.

Контракты, uniform syntax, alias this, immutable, императивные шаблоны — синтаксический сахар, при этом не приводящий к уменьшению размера кода.

Контракты, uniform syntax, alias this, immutable, императивные шаблоны — синтаксический сахар, при этом не приводящий к уменьшению размера кода.

Машинного кода?

Нет, имею ввиду именно код на языке.

так, на русском нельзя написать компилятор, а на английском можно

Тогда покажи, как будет выглядеть такой D-код на Си++.

struct Foo
{
  int baz = 4;
  int get() { return 7; }
}

class Bar
{
  Foo foo;
  alias foo this;
}

void test() {
  auto bar = new Bar;
  int i = bar.baz; // i == 4
  i = bar.get(); // i == 7
}

а что им мешало с самого начала писать методом раскрутки вместо наращивания кодовой базы

Сам-то понял, что сказал? Еще разок вдумайся и представь процесс: писать компилятор на языке, для которого еще нет рабочего компилятора. Такое могут предложить только эксперты с ЛОРа-опеннета.

Кошернее же rust-у (в теории) дать возможности быть поближе к железу, чем приделывать высокоуровневые костыли к D, не-а?

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

Умные указатели не могут заменить GC, а вот GC может заменить умные указатели. Хотя, иногда, они полезны.

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

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

Вам надо посмотреть на rtti delphi, хотя бы, для того чтобы понять что такое настоящий rtti.

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

Ты же понимаешь, что это мошенничество.

Умные указатели не могут заменить GC, а вот GC может заменить умные указатели. Хотя, иногда, они полезны.

Однако я лишь считаю, что умные указатели достаточны для C++, а остальные фичи сборщика мусора либо помешают, т.к. ухудшат контроль над временем жизни объектов, либо нуждающаяся в GC часть программы может быть написана на скриптовом языке, что даст более качественную изоляцию и средства отладки.

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

Возможно, мы понимаем под модульностью разные вещи. Если вы про отказ от include и замену на импорт символов, то ввести его можно и именно это стало бы наиболее приятной фичей c++14 или c++17. Если про разделение на .h/.cpp, то я это считаю преимуществом, а не недостатком.

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

Писать плохо можно на любом языке, в том же D (да и в C++) автоматически расширяемым массивом можно забить всю память. А писать без адресной арифметики возможно.

Вам надо посмотреть на rtti delphi, хотя бы, для того чтобы понять что такое настоящий rtti.

Извините, но я не собираюсь смотреть rtti в Delphi. Меня Qt-шный устраивает.

Почему другим это не мешает писать программы, а автору сайта мешает?

Ты же понимаешь, что это мошенничество.

скорее это неудачно выбранный пример для задачи

Что - мошенничество? Использование c++11, который гораздо ближе, чем ещё даже не стабилизировавшийся D? Если c++11 где-то ещё запрещён, это никак не аргумент - в тех проектах использование D будет запрещено тем более.

он имел ввиду это:

http://dlang.org/class.html#AliasThis

вот только копипащенный пример не показывает каких либо преимуществ alias this, примеры по ссылке ниже - тоже

вот только копипащенный пример не показывает каких либо преимуществ alias, примеры по ссылке ниже - тоже

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

Аналогично - с friend, по мне так он лишь лучше иллюстрирует связи объектов и тем самым сокращает время на их поиск.

alias this - не наследование

Что - мошенничество? Использование c++11

В данном случае мошенничеством является использование наследования.

Multiple AliasThis are allowed.
Note: Multiple AliasThis is currently unimplemented.

LOL, а они еще о переписывании компилятора думают

скорее это неудачно выбранный пример для задачи

Я считал очевидным, что нужно продемонстрировать код, не использующий наследования.

Я считал очевидным, что нужно продемонстрировать код, не использующий наследования.

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

А почему вы не предложили написать код, не использующий C++?

Потому что меня интересует сравнение объемов кода на Си++ и D.

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

Модульность имеет вполне конкретное определение. В С++ ее нет и не будет. Разделение на h и cpp это атавизм.

Можно. Нос таким подходом лучшим языком будет ассемблер.

Жалкая пародия на настоящий rtti. Что-то подобное можно сотворить даже на ассемблере.

Странно, почему не руби?

наследование по нынешним понятиям вообще не очень хорошая практика - слишком сильный coupling даёт. Ну и alias this не вводит никаких виртуальных функций (в вашем варианте нужен хотя бы виртуальный деструктор).

Это D1 появился. С D2 у него общего не так уж много. А D2, кажется, с 2008 делается.

«alias this» - можно объявить переменную-член класса (или структуры) таким алиасом

Только одну переменную или можно несколько? Если второе, то как-то конфликты разруливать можно?

Тогда уж так:

struct Foo
{
   int baz = 4;
   int get() { return 7; }
};

struct Bar : private Foo
{
   using Foo::baz;
   using Foo::get;
};

int main() {
   Bar bar;
   cout << bar.baz << endl; // 4
   cout << bar.get() << endl; // 7
   
   return 0;
}

Правда писать придётся всё-таки чуть-чуть побольше, чем при использовании Дишного alias. Только интересно как там конфликты решать предполагается.

наследование по нынешним понятиям вообще не очень хорошая практика - слишком сильный coupling даёт.

Да, но разве alias сильно лучше?

Ну и alias this не вводит никаких виртуальных функций (в вашем варианте нужен хотя бы виртуальный деструктор).

Скорее в данном примере new нафиг не нужно. Тогда и без деструктора можно обойтись.

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

Почему бы это не делать компилятору?

Зачем тащить весь необработанный мусор в «выпрямленный» язык программирования. После конвертации заголовков в модули, из оных можно выбросить биндинги к проблемным системным функциям а также написать обёртки не сношающие мозг. Например printf это ужас на крыльях С а write и writeln кавай и ништяк даже если _в_линуксе_ они имеют имеют под капотом printf. В Ди пошли по пути понимания заголовков компилятором, хотя до этого как-то обходились, а значит понатащут в язык чужеродных С++ конструкций и закопают под ними смысл своего языка.

А как в Ди у динамических массивов увеличивается длина: увеличивается автоматически при использовании или перед использованием надо задавать конкретную длину?

Зачем здесь задавать точечные вопросы, когда можно тупо пойти на сайт и почитать?
У Ди-шных массивов можно как увеличивать автоматом (просто добавляя элемент), так и распределяя заранее - т.е. всегда есть возможность, в зависимости от задач, управлять предсказуемостью работы с памятью.

Ээээ, я правильно понял: только от самого переписывания реализации на другом языке архитектура вдруг из кривой становится просто таки идеалом красоты?

Не хочется вас огорчать, но для вашего уровня знаний - да. :)

Архитектура (если просто на уровне модулей) - да, она везде одинаковая. Но как только спускаешься к деталям, тут же, по самые гланды, получаешь жёсткую зависимость от возможностей языка. И если, скажем, GC в языке работает плохо, на нём сразу можно ставить крест и переписывать всё на Си с malloc.
Даже наличие множественного наследования тоже может конкретно вывернуть общую структуру проекта.
Так что язык важен и «умные структуры» будут играть главенствующую роль (и только потом уже алгоритмы).

Либа одна - Phobos.

А язык то марсианский!

Зачем здесь задавать точечные вопросы, когда можно тупо пойти на сайт и почитать?

Потому что здесь есть специалист по этому сайту который его читал и ответит на вопросы быстрее но не факт что полнее.

У D две главных проблемы - дизайнеры (один - компиляторщик, другой - акробат от Си++)

эээ... а в чём проблема иметь опытного «компиляторщика»?? Не это ли гарантия того, что язык не скатится к реализации «популярных плюшек» (как C#) ?

И потом, у Ди есть один серьёзный бенефит - он УЖЕ ОБКАТАН, а что покажется спорным - выкинут по дороге. Т.е. когда мужики возьмутся за «Ди на Ди», у них уже будет одна конкретная цель. Плюс, «опыт коллег» на Roslyn. Так что дрова есть, спички есть, осталось зажечь и улететь! :)

Например printf это ужас на крыльях С а write и writeln кавай и ништяк даже если _в_линуксе_ они имеют имеют под капотом printf.

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

В Ди пошли по пути понимания заголовков компилятором,

Откуда инфа?

Ну и смысл? Теперь ты знаешь кое-что о массивах, это ВСЁ, что тебе мешало начать писать на Ди? :)

Язык - либо надо конкретно читать и пробовать все его фичи, либо просто взять на заметку «есть такой язык». А спрашивать по форумам «а умеет ваш %%%%% вот так?» - нет смысла, ни себе польза, и людей отвлекаешь.

Спеки D я немного читал, но так и не нашёл сильных улучшений. Ну нет препроцессора, а других улучшений не вижу. Только странное разделение на структуры и объекты, где объекты создаются только в куче.

Скопировали две фичи из объектпаскаля - типы переменных и объекты создаваемые с ключевым словом class. Работу с заголовками слямзить не смогли.

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

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

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