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

Цитата MyNameIsIgor @ 11.02.14, 13:19

Они же должны быть разложены по директориям, а вместо #ifdef должны использоваться либо порождающие паттерны, либо языковые механизмы типа одного .h и по .cpp на конкретную реализацию.

Хм. Не очень себе это представляю в header only библиотеке, например.

Цитата D_KEY @ 11.02.14, 13:43

Хм. Не очень себе это представляю в header only библиотеке, например.

Настройка путей include'а.

Цитата MyNameIsIgor @ 11.02.14, 13:45

Цитата D_KEY @ 11.02.14, 13:43

Хм. Не очень себе это представляю в header only библиотеке, например.

Настройка путей include'а.

В системе сборки? Ну можно, в принципе, да. Но это придется делать каждому пользователю библиотеки.

Далее.
Sociomatic Labs специализируется на, хз как это перевести - real-time bidding for online display advertising. Вся их кодовая база написана на D. Правда, справедливости ради, надо отметить что на D1/Tango.

Цитата D_KEY @ 11.02.14, 13:47

Но это придется делать каждому пользователю библиотеки.

Почему же? Система сборки не может определить текущую ОС и архитектуру?

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

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

На D написана высокопроизводительный

Как определили, что он высоко производительный?

Цитата korvin @ 11.02.14, 13:50

Цитата D_KEY @ 11.02.14, 13:47

Но это придется делать каждому пользователю библиотеки.

Почему же? Система сборки не может определить текущую ОС и архитектуру?

Ну да, в принципе, можно именно полностью управлять точным набором хидеров и ставить только их, если ты об этом. И для текущей ОС и архитектуры это не будет большой проблемой, но вот всякие флаги компиляции и конфигурации(boost.config например)... В общем случае, как мне кажется, это не сделать. Но во многом я с вами согласен.

Добавлено 11.02.14, 13:59

Цитата applegame @ 11.02.14, 13:48

real-time bidding for online display advertising

Торги реального времени для показа рекламы Это известная шляпа, система для проведения аукциона между рекламными сетями.

Эй, не отклоняемся от темы.

Цитата D_KEY @ 11.02.14, 13:55

В общем случае, как мне кажется, это не сделать

Да, в общем случае для плюсовых header only библиотек этого не сделать. Но даже если #ifdef будет только вокруг #include, будет уже хорошо.

Добавлено 11.02.14, 14:06

Цитата applegame @ 11.02.14, 14:03

Эй, не отклоняемся от темы

А в чём состоит тема? Чтобы показать в лучшем случае несколько десятков проектов на D против стопитсот проектов на C++?

Цитата MyNameIsIgor @ 11.02.14, 14:05

Но даже если #ifdef будет только вокруг #include, будет уже хорошо.

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

D так устроен, что для небольших проектов можно легко обойтись без системы сборки вообще. В D встроен JIT компилятор, так что скрипт занимающийся сборкой может быть на самом D. Это часто очень удобно. В линупсе просто стартуем скрипт, в Windows стартуем через rdmd.

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

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

Неинтересно. Для небольших проектов хоть Brainfuck прокатит.

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

Цитата applegame @ 11.02.14, 14:13

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

Совсем этим я согласен как раз. Мы тогда говорили о выигрыше при переходе с C++ на D.