D vs C++ , почти сурковская пропаганда: не пора ли C++ потихоньку готовиться к пенсии?

[applegame]

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

Для начала хочу отметить, что D стремительно набирает популярность в мире. По версии tiobe.com, индекс D за один год поднялся с 36-места до 18-го и теперь язык входит в топ-20.
На него все больше и больше обращают внимание крупные коммерческие организации, например:
- швейцарская компания CSCS специализирующая на разработке ПО для суперкомпьютеров;
- Facebook;

Кроме "родного" кроссплатформенного компилятора DMD, существуют также компилятор на базе LLVM: LDC и на базе GCC: GDC.

В чем основное преимущество D перед C++ лично для меня? В первую очередь - это значительно более мощные возможности метапрограммирования, поверьте, C++ до такого уровня, как пешком до Луны. При этом конструкции в D, как правило, выглядят намного проще аналогов из C++, даже учитывая долгожданные нововведения стандарта C++11.
Преимущества перед C++:
- встроенные ассоциативные массивы.
- тип real (идеален для математических вычислений);
- мощный и в тоже время простой синтаксис шаблонов;
- примеси (mixins);
- отсуствие необходимости в заголовочных файлах (это свобода, вы плюсовики, просто не знаете как это прекрасно);
- Настоящая условная компиляция в зависимости от ключей в командной строке, процессора, кода, версии и т.п.;
- настоящий CTFE, вплоть до compile-time импорта в строку и парсинга файла в код на D;
- встроенные делегаты;
- нормальные лямбды, тип которых зависит напрямую от сигнатуры, а не как компилятор на душу положит. Кроме того имеется прекрасный сокращенный стиль их написания;
- встроенный TLS (thread local storage) - это реально круто;
- встроенный compile-time reflection: можно разобрать по косточкам класс/структуру/функцию и на основании этого сгенерить нужный код;
- ????
- PROFIT!!!!

Справедливости ради, минусы D:
- сборщик мусора, к тому же еще и не самый продвинутый;
- сам язык, к сожалению, еще до конца строго не определен, из-за чего при смене версий, могут вылезать предупреждения об устаревании.
- некоторые части стандартной библиотеки Phobos - ужасающи, и некому их переписать.
- слабая "обвязка": мало библиотечек, IDE. компиляторов, инструментов и т.д; хотя, надо признать, сейчас ситуация весьма лучше чем пару лет назад.

Для начала холивара, вот вам сравнение двух идентичных кусков кода на C++ и D:

C++

#include <type_traits>
#include <iostream>
    
template<class T>
typename std::enable_if<std::is_floating_point<T>::value, T>::type foo1(T t) {
    std::cout << "foo1: float\n";
    return t;
}
    
template<class T>
typename std::enable_if<std::is_integral<T>::value, T>::type foo1(T t) {
    std::cout << "foo1: int\n";
    return t;
}
    
int main() {
    foo1(1.2);
    foo1(10);
}

D вариант 1

import std.stdio;
import std.traits;
 
T foo1(T)(T t) if(isFloatingPoint!T) {
    writeln("foo1: float");
    return t;
}
 
T foo1(T)(T t) if(isIntegral!T) {
    writeln("foo1: int");
    return t;
}
 
void main() {
    foo1(1.2);
    foo1(10);
}

D вариант 2

import std.stdio;
import std.traits;
 
T foo1(T)(T t) {
    static if(isFloatingPoint!T) {
        writeln("foo1: float");
    } else static if(isIntegral!T) {
        writeln("foo1: int");
    } else {
        static assert(false, "type: '" ~ T.stringof ~ "' is not allowed");
    }
    return t;
}
 
void main() {
    foo1(1.2);
    foo1(10);
    foo1("test"); // static assert with message
}

Сообщение отредактировано: applegame - 11.02.14, 06:54

[D_KEY]

У меня дежавю?

[applegame]

Цитата D_KEY @ 11.02.14, 07:11

У меня дежавю?

Ну времени прошло много, многое поменялось. Пора снова просвещать массы

[Мяут-Настоящий]

D это такая Java с плюшками как в Scal'е для C++сников?

Цитата applegame @ 11.02.14, 06:53

встроенный

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

[D_KEY]

Встроенные ассоциативные массивы? Зачем? Не ПХП вроде. А есть выбор между хэш-таблицами и деревьями?

Тип real? Это который long double?

Плюшки шаблонов не в синтаксисе. Надо задачки решать, чтоб сравнивать.

Примеси там не из-за отсутствия множественного наследования, случаем?

Не, так неудобно отвечать, чуть позднее напишу с компа

Сообщение отредактировано: D_KEY - 11.02.14, 07:23

[Wound]

А что на счет тестов производительности?

[Повстанець]

Опоздал язык D в своём явлении миру лет эдак на 10, минимум. Времена языков общего назначения давно прошли. Но это так.. к слову.

А вообще достоинства D выглядят хорошо только на первый взгляд. На самом деле в средненьком таком проекте никто не пишет сложный, сверхгибкий шаблонный код. Весь он уходит в библиотеки. В лучшем случае -- в утилитарный код, либо куда нить на нижние слои архитектуры, для придания гибкости. В остальном -- стандартненькое ООП, где шаблоны и прочие плюшки по большей части юзаются, нежели создаются. И будь эти все фишки хоть в 10 раз проще, это не сэкономило так уж много времени. В остальном, С++ ценится за хороший контроль потребления ресурсов и за совместимость с С. Там где не надо так уж заботится о ресурсах и не нужна совместимость с С (частенько это просто идёт рука об руку), легче использовать всякие явашарпы, в зависимости от области.

ИМХО, очень тяжело подобрать задачи, где нужен был бы язык, более высокоуровневый, чем С++ и менее высокоуровневый, чем явашарпы всякие.

[Flex Ferrum]

applegame, с учётом того, что сейчас творится в рабочих группах комитета по стандартизации C++ - все эти плюшки весьма сомнительные.

[applegame]

Цитата Мяут-Настоящий @ 11.02.14, 07:22

D это такая Java с плюшками как в Scal'е для C++сников?

Не знаю, как в Scala. На жабу не похоже. Гораздо ближе к плюсам, да и компилится в нативный код.

Цитата D_KEY @ 11.02.14, 07:23

Встроенные ассоциативные массивы? Зачем? Не ПХП вроде. А есть выбор между хэш-таблицами и деревьями?

Ассоциативные массивы очень часто используются, так что сделать их одним из базовых типов, ИМХО, верный ход. Выбора нет, в D ассоциативные массивы - это всегда хэш-таблицы. Для деревьев есть стандартная библиотека с соответствующими шаблонами.

Цитата D_KEY @ 11.02.14, 07:23

Тип real? Это который long double?

Близок. Стандарт четко его описывает как максимально большой тип поддерживаемый железом.

Цитата D_KEY @ 11.02.14, 07:23

Плюшки шаблонов не в синтаксисе. Надо задачки решать, чтоб сравнивать.

Давай задачу, или я могу дать. Я решаю в D, ты в плюсах , вот и сравним.

Цитата D_KEY @ 11.02.14, 07:23

Примеси там не из-за отсутствия множественного наследования, случаем?

В частности, но они и сами по себе весьма хороши, я тебе скажу.

Цитата Wound @ 11.02.14, 07:24

А что на счет тестов производительности?

Вполне достойно: раз, два.

Добавлено 11.02.14, 07:47

Цитата Повстанець @ 11.02.14, 07:27

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

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

Добавлено 11.02.14, 07:50

Цитата Flex Ferrum @ 11.02.14, 07:33

applegame, с учётом того, что сейчас творится в рабочих группах комитета по стандартизации C++ - все эти плюшки весьма сомнительные.

Это мы еще посмотрим. Комитет по стандартизации - дикий тормоз, а еще ведь нужно ждать пока все эти новшества будут добавлены в компиляторы. А в D - это уже есть: здесь и сейчас.

[OpenGL]

Помню, когда ковырялся с D, наткнулся на то ли баг, то ли фичу их реализации интерфейсов. В яве и шарпе интерфейс по-сути предъявляет требования к наличию методов, но откуда они были получены - неважно. Пример:

interface IFoo
{
    void f();
    void g();
};
 
class Base
{
    void f();
};
 
class Derived : Base, IFoo
{
    void g();  // Этого достаточно - f реализована в базовом классе
};

В D же такое не компилится - говорит, что интерфейс реализован не до конца. Имхо, это не совсем корректное поведение

[Flex Ferrum]

Цитата applegame @ 11.02.14, 07:41

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

Это сомнительное преимущество. Простой шаблон и в C++ несложно написать. А вот когда речь заходит о чём-то более сложном - тут уже проблема не столько в синтаксисе, сколько в том, чтобы это сложное адекватно спроектировать.

Цитата applegame @ 11.02.14, 07:41

Это мы еще посмотрим. Комитет по стандартизации - дикий тормоз

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

Цитата applegame @ 11.02.14, 07:41

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

Сейчас два из трёх mainstream-компилятора идут ноздря-в-ноздрю с комитетом. Что gcc, что clang уже активно запиливают новые фичи.

[applegame]

Цитата OpenGL @ 11.02.14, 08:03

Помню, когда ковырялся с D, наткнулся на то ли баг, то ли фичу их реализации интерфейсов.

Это фича. Почему так сделано не знаю, описано здесь - http://dlang.org/interface.html
Добавлено 11.02.14, 08:18

Цитата Flex Ferrum @ 11.02.14, 08:08

Сейчас два из трёх mainstream-компилятора идут ноздря-в-ноздрю с комитетом. Что gcc, что clang уже активно запиливают новые фичи.

Ну таки не ноздря в ноздрю. Да и сlang + windows = головная боль.
Короче, как говорится: поживем - увидим.

Сообщение отредактировано: applegame - 11.02.14, 08:18

[D_KEY]

Цитата applegame @ 11.02.14, 06:53

отсуствие необходимости в заголовочных файлах (это свобода, вы плюсовики, просто не знаете как это прекрасно)

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

Цитата

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

А при использовании препроцессора она не настоящая? А для D я смогу задать какие-то константы через систему сборки?

Цитата

настоящий CTFE, вплоть до compile-time импорта в строку и парсинга файла в код на D

Попадались мне разные тесты, которые показывали, что как-то не очень там все. Впрочем, не найду сейчас

Цитата

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

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

Цитата

встроенный TLS (thread local storage) - это реально круто

Чем это принципиально отличается от возможностей C и C++?

Цитата

встроенный compile-time reflection: можно разобрать по косточкам класс/структуру/функцию и на основании этого сгенерить нужный код

Это гуд. А можно парочку примеров?

Цитата

сборщик мусора, к тому же еще и не самый продвинутый

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

[applegame]

Цитата OpenGL @ 11.02.14, 08:03

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

Короче покопал тему. В плюсах сделано также как и в D: http://ideone.com/q5rgmu, И это сделано правильно.
Интерфейс - это требование реализации, а не просто наличия. Кроме того, интерфейс - это еще и базовый тип с виртуальными функциями f() и g(). Класс Base в твоем примере никакого отношения к IBoo не имеет, соответственно функция интерфейса f() в классе Derived не реализована и не может быть вызвана через тип интерфейса. Хз как это сделано в этих ваших явах и шарпах.
Наличие можно проверить по другому и интерфейсы здесь вообще-то не нужны.

[D_KEY]

Цитата applegame @ 11.02.14, 07:41

Ассоциативные массивы очень часто используются, так что сделать их одним из базовых типов, ИМХО, верный ход.

Какие плюсы от встраивания в язык?

Цитата

Близок. Стандарт четко его описывает как максимально большой тип поддерживаемый железом.

У D, если что, нет стандарта.

Цитата

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

Не согласен Шаблоны, как правило, действительно наиболее полезны в библиотеках и "утилитарном" коде. Хотя и не всегда.

Цитата

А в D - это уже есть: здесь и сейчас.

Вопрос в том, есть ли здесь и сейчас сам D и в каком он состоянии.

Добавлено 11.02.14, 08:45

Цитата applegame @ 11.02.14, 08:12

Цитата OpenGL @ 11.02.14, 08:03

Помню, когда ковырялся с D, наткнулся на то ли баг, то ли фичу их реализации интерфейсов.

Это фича.

Плохая фича.

Добавлено 11.02.14, 08:46

Цитата applegame @ 11.02.14, 08:34

Короче покопал тему. В плюсах сделано также как и в D

Нет, не так же. В плюсах нет интерфейсов.