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

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

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

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

Цитата D_KEY @ 11.02.14, 12:29

А если у меня зависимость от версии ОС, архитектуры, конкретной POSIX'овой или SUS-константы?

Если у тебя какие-то сложные правила сборки, то ты всегда можешь воспользоваться make. В большинстве случаев этого достаточно: http://golang.org/pkg/go/build/

Кстати, что за POSIX/SUS-константы?

Цитата OpenGL @ 11.02.14, 12:42

Кстати, что с ними в D? Считал, что там есть нормальные деструкторы как в плюсах. Это неверно?

Есть там деструкторы, но классические плюсовые деструкторы с GC не уживаются, ибо он недетерминирован.
Я когда книжку читал, был разочарован. Сейчас уже забыл за ненадобность. Могу потом написать, когда добирусь до дома и открою книгу. Или вон D_KEY может вспомнить - он тоже читал.

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

Внезапно, в разных версиях могут быть разные API(если мы о винде) или разная степень и подход к реализации стандартов(если мы о *nix).

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

Добавлено 11.02.14, 12:53

Цитата korvin @ 11.02.14, 12:46

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

Это смотря с какой стороны смотреть. С одной стороны костыль, с другой стороны гибкость. Кроме того version позволяет условно компилять не только в зависимости от платформы, но и как классический #ifdef в зависимости от аргументов командной строки, или в зависимости от режима debug/release и т.п.

Добавлено 11.02.14, 12:59
Для объектов созданных с помощью new (читай классов) деструкторы практически бесполезны, так как действительно не детерминированы, то бишь вызываются, когда приспичит GC, причем в одному ему ведомом порядке. Для объектов создаваемых на стеке (читай структур) деструкторы детерминированы и работают аналогично плюсовым. Поэтому на базе структуры можно создать аналог shared_ptr, который будет вызывать деструктор уже вполне детерминировано.

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

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

зависимости от платформы, но и как классический #ifdef в зависимости от аргументов командной строки, или в зависимости от режима debug/release и т.п.

Да-да, и снова греп и каша в сорцах... =)

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

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

Внезапно, это зависит от проекта. Да и от политики установки программ в ОС. Скажем, порты во FreeBSD собирают софт перед установкой

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

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

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

Нет, спасибо. Я предпочитаю автоматизацию. Даже разворачивать систему автоматически, при помощи того же ansible, например. Может и это в язык сунуть?

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

Да-да, и снова греп и каша в сорцах... =)

А как по другому? Отдельные файлы с исходниками для дебаг-версии, отдельно для релиз?

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

Да-да, и снова греп и каша в сорцах... =)

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

Сообщение отредактировано: MyNameIsIgor - 11.02.14, 13:21

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

Может и это в язык сунуть?

Вообще в D вставлено ровно две вещи: тип OS и архитектура, остальное внешними ключами.

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

А как по другому?

Вот, ещё один...

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

Отдельные файлы с исходниками для дебаг-версии, отдельно для релиз?

А у вас разный код исполняется в debug и в realese? Тогда тестирование debug версии не имеет смысла - у клиента будет работать другой код.

Сообщение отредактировано: MyNameIsIgor - 11.02.14, 13:21

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

А у вас разный код исполняется в debug и в realese?

В релиз версии не выполняются некоторые проверки, которые делаются в дебаг-версии. Так что код, да, слегка различается.

Добавлено 11.02.14, 13:26
Продолжаем тему используемости D. Вот эта контора - http://www.funatics.de/en/ делающая, насколько я понял браузерные MMO игры, начала миграцию игрового бэкенда с NodeJS на D.

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

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

В релиз версии не выполняются некоторые проверки, которые делаются в дебаг-версии. Так что код, да, слегка различается.

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

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

В релиз версии не выполняются некоторые проверки, которые делаются в дебаг-версии.

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

Сообщение отредактировано: MyNameIsIgor - 11.02.14, 13:35

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

начала миграцию игрового бэкенда с NodeJS на D.

Не удивительно, с NodeJS грех не мигрировать. При этом практически не важно на что. Даже Ryan Dahl ненавидит NodeJS. =)

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

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

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

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

Из релизной версии могут выпиливаться контракты, юниттесты (которые опять же могут лежать в отдельных файлах) или другие проверки.

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