Russian Qt Forum

В чем язык D лучше\хуже С++?

"Он является языком сверхвысокого уровня"
ИМХО, после этой фразы сравнивать C с D тоже, что сравнивать C с ASM.

Где такое пишут?

Ну и всеже, что в нем такого "сверхвысокого"? В чем он "выше" С++?

Здесь можно почитать http://ru.wikibooks.org/wiki/%D0%AF%D0%B7%D1%8B%D0%BA_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F_D (http://ru.wikibooks.org/wiki/%D0%AF%D0%B7%D1%8B%D0%BA_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F_D)

А нет случайно для студи плагина c D?

Помоему есть только GCC для D

Почитал.

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

Вобщем С++ наше всё )))

Для C++ вроде тоже библиотеки сборщика мусора есть.
Остальные нововведения вообще не понял, просто немного другой синтаксис. С библиотекой тоже непонятки, неужели там статической линковки нет?

да уж, лучше питон начать изучать.  ;D

Почитайте вот это

http://xen.rwx.ru/coding/42.1 (http://xen.rwx.ru/coding/42.1)

(все три страницы).


Для особо ленивых основные моменты:

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

Именно так и нужно делать.

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

Кто бы с этим поспорил.

Теперь везде можно писать "." и не париться.

Это хорошо, как же без них. Теперь map структуры ненужны.

Все чотко и понятно, не нужно выяснять "контекст использования". Лексические и синтаксические анализаторы выполняются в один линейный проход и работают с дикой скоростью.

Наконец то.

А в D мы что видим в прототипе, то и получаем.

А в D мы видим тип переменной массива:
int[10] a; // а - это массив из десяти int чисел. Потому что a имеет тип int[10]. Логично, не так ли?
int[3]* b; // объявляется ссылка на массив из трех целых чисел

И это правильно.

UPD:

А значит теперь невозможна ошибка использования "=" вместо "==" в условиях.

вот-вот, ничего особо значимого в язык не добавили.

помоему, с Оберона содрали, только синтаксис Си, плюс засунули препроцессор в язык.

Для кого предназначен язык D

• Для людей, которые компилируют код с максимальным количеством включенных уровней предупреждений (warning levels), что означает интерпретацию предупреждений как ошибок;
• Для тех, кто решил, что обещание легкого объектно-ориентированный подхода к программированию в языке C++ не выполняется из-за его сложности и запутанности;
• Для программистов, которых впечатляет мощь языка C++, но разочаровывает необходимость ручного управления памятью и ловля багов, связанных с указателями;
• Для команд разработчиков, разрабатывающих приложения, исходные тексты которых содержат миллионы строк кода;
• Для программистов, которые считают, что язык программирования должен поддерживать достаточное количество возможностей для абстрактной работы с указателями;

Для кого не предназначен язык D

• Для маленьких программ, для которых больше подойдут языки скриптования или интерпретируемые языки, например Python или Perl;
• Для борцов за чистоту языка. D является практичным языком и каждая его особенность реализуется таким образом, чтобы сохранить эту практичность. Например, в языке D нет необходимости использовать указатели в ординарных ситуациях, но работа с указателями поддерживается.

Для вас, уважаемые, язык D не предназначен.

Множественное наследование, там где оно есть в полной мере используется в основном 3мя способами:
Наследование интерфейсов, миксины, интеграция нескольких разных библиотек в один проект.
В Java и C# два последних вида невозможны.

Миксины, например, используются в Qt, когда мы наследуем наш класс от QDialog и сгенерённого из ui-шки класса.
Вроде бы миксины в Д есть.

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

Предупреждение - это когда синтаксис корректен, но сама конструкция может иметь неожиданный для разработчика смысл.
Например, gcc выдаёт предупреждение, если в списке инициализации базовые классы и поля указаны в порядке отличном от порядка их объявления. Так же у него есть режим, когда предупреждения выдаются по советам Мейерса. :)
Как-то довольно долго ловил ошибку из за неверного порядка - я то смотрел на порядок инициализаторов. :)
Хотя конечно,

Чем плох std::map?

Опять же чем плохи std::vector или boost::array?
Чистыми массивами пользуются обычно для буферов, для обмена с plain C, и студенты. :)
Оно конечно [] написать быстрее чем array, но не критично.

Присвоение в С++ возвращают то, что описано в сигнатуре. По умолчанию объект, для которого выполнялось присвоение.
Так что если объект не приводится к bool или void* то и спутать невозможно.
Зато возможна конструкция a = b = c = 10;

Моё мнение: D нужно сравнивать с C# или Java, т.к. он ориентирован примерно туда же. А с С++ но несколько в разных плоскостях.
Кроме того, в D нет ничего принципиально нового или отличного от всех перечисленных,
По мне, если уж и переходить куда-то, то в скриптовые или функциональные. Оба направления дают изрядный выигрыш в скорости разработки, причём вторые ещё и скорость выполнения дают вполне на уровне. :)
Ну и изучая кардинально другие направления ты изрядно расширяешь кругозор. :)

П.С. Мне кажется, что D появился в большой степени потому, что в OpenSource долго не было языков класса C# или Java.

В D модули, конечно, можно объединять в пакеты.


Да впринципе ничем не плох. Но реализация сделана в отдельном namespace std, и об этом надо помнить при программинге. Просто неудобно. А тут часть языка.


Да тоже хороши. Но std::vector - это всетаки не массив. А boost::array - вообще не часть стандарта языка.


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


Принципиально новое - это то, что низкоуровневый язык приближается по своему удобству к C# или Java. Это на самом деле много стоит, ведь программы пишут люди, а не только биороботы с красными фотоэлементами:).

Решил переписать свою программу на C++/Qt только потому что теперь в Qt есть очень хорошая интеграция со скриптами. Итого вся программа будет написана на скриптах процентов на 80 + поддержка плагинов на тех же скриптах.
Писать все на C++, да и на том же D или C#, было бы очень нудно и тоскливо.

Язык бессмысленно использовать без нормального отладчика/IDE. Какая разница какие там массивы или модули в самом языке если в случае проблемы ее долго исправлять. О каких миллионах строк кода идет речь когда нет нормальной среды с отладчиком/системой тестирования для поддержки такого проекта.

Смотря что понимать под "частью языка". если то, что описано в его стандарте, то std::map тоже часть языка.
Почему написание слова template перед шаблоном тебя не смущает, а std:: вызывает трудности?

Да std::vector больше чем просто массив - это массив с динамической длинной.
А boost::array если я не ошибаюсь включен в следующий стандарт. :)


Сможешь с ходу сказать какое свойство мешает транслировать C# или Java в натив?
И что, собственно делают JIT-ы в этих языках?
И что получится, если JIT-компиляцию провести заранее? :)

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

Интересно узнать от гуру, по каким критериям он нам не предназначен?? о_О

Попробую написать почему лично мне нравится D. Кое-что основывается на ощущениях и впечатлениях, но также постараюсь привести сухие факты.
С++ - это язык, где аккуратно расставлены грабли. Это не моя фраза но тем не менее она верна. Чтобы сделать что-то более менее рабочее помимо изучения толстой книги по самому языку я посчитал обязательным к прощению обеих книг Мейерса - без этого просто невозможно обходить грабли. Эксперты С++, имхо, помимо всего прочего потому и эксперты, что знают как делать нельзя.
Далее С++ тянет из С, языка 40 летней давности ужасные решения как #include, макросы, классы по умолчанию - типы по значению. Данный форум посвящен к Qt. Qt - это яркое доказательство того, что С++ ужасен, потому что этот фреймворк существенно расширяет язык и пытается улучшить то, что лежит в его основе.
Насчет встроенных Правильных массивов, ассоциативных массивов и строк - непонятно почему язык не должен этого иметь? Это С++ породил QVector и std::vector, QString, std::string и char*.
Синтаксис С++ ужасен. D спроектирован изначально правильно. Вы бегло пробежавшись по сайту digitalmars.com решили что это еще один язык из семейства C и кардинальных плюсов не приносит по сравнению с С++. Преимущества проявляются во всем, перечислю лишь некоторые из них:

auto - плюсисты только в С++09 подошли к тому что неплохо бы его использовать
конструкции типа QAbstractItemModel::QAbstractItemModel() для конструкторов и деструкторов
отсутствие различий между . и ->
nested structs, types, functions - точно не знаю как с этим в С++, но когда я портировал давным давно свою программу на gcc - он запретил мне это
scope - чертовски удобная фича
foreach - лишнее подтверждение что Qt костыль
инициализация элементов массивов по умолчанию(если вам хочется производительности - D как системный язык легко позволяет это сделать)
и многое другое. на самом деле различных маленьких удобств настолько много, что чтобы это понять, надо попробовать писать на нем.

Теперь по поводу ключевых преимуществ:
1) мгновенная компиляция
2) отсутствие препроцессора, но вместо него набор отличных средств
  version
  static if
  static assert
3) модульная система, вместо #include, который иначе как asspain не назовешь
4) управление памятью. Это тема для отдельного разговора. Но хочу сказать что это ключевое преимущество. Для любителей извращений сборщик мусора легко отключается. Другая возможность - комбинировать сборщик мусора с ручным выделением памяти - имхо идеальный вариант. Еще одно подтверждение огромных возможностей языка
5) нормальная объектная система - никакого множественного наследования, а интерфейсы и mixin's
6) делегаты - их наличие позволяет не городить костылей в виде moc, а реализовывать все просто и красиво.
7) я пока мало использую шаблоны, но по впечатлением людей - они мощнее чем в С++. ИМХО самым ярким впечатлением этого является то что уже как 3 года вторым разработчиком языка является Андрей Александреску, возможно вы читали его книги. Он забросил С++ - как думаете - это авторитетное мнение?

Вот хорошая табличка - http://www.digitalmars.com/d/1.0/comparison.html там конечно более полный список.
Нет ни одной задачи, которую бы было легче и удобнее реализовать в С++ чем в D. D - язык с огромными возможностями, превышающими таковые у С++ и превращающие программирование в удовольствие.
Можете также зайти на dprogramming.ru - русское сообщество пользователей D.

Насчет IDE - вы спросите вначале на чем Qt разрабатывают. Приятно удивитесь, что это не Microsoft Visual Studio. С отладчиком несколько больше пробем, но под вин32 есть хороший отладчик. С линуксом дело обстоит хуже.

Эклипс как бе считается нормальным IDE. Хотя многим хватает что-то в стиле kate. Красноглазам емакса хватае за глаза.

gdb он и в Африке gdb, можно или напрямую дебажить, или изнутри эклипса, или всякими надстройками в стиле ddd или kdbg. Все привязывается к коду, не знаю правда, почему Eldar говорит что для D отладчика нет, по идее для gdb должно быть фиолетово, какой язык дебажить, если в бинаре есть extendet код для дебага. Но тут надо уже с практиками говорить. Я к языку этому пока только присматриваюсь.

Да что ж вы все о себе да о себе? :) Не предназначен он для тех, кто не понимает дастоинств языка. Зачем ему этот язык? Пусть пользует C/C++, скоро вон новая версия подоспеет кстати.

Невпечатлило...

1) Это конечно важно, но из-за это го бы не перешл на него
2) Использую только стражи включения
3) Нечувствую нималейшего дискомфорта
4) Ненужно. Хороший программист сам себе сборщик мусора. Это зависит от кривизны рук девелопера.
5) Пользуюсь множественным наследованием. Невижу ничего плохого в его использовании. Может вы объясните мне?
6) А подробнее про кастыли? И что предоставляют делегаты?
7) Не являеться решающим фактором. Есть библиотеки расширения для С++. Мнение Александреску тоже не являеться решающим фактором. Миллионы программистов пишет на С\С++: операционки, ПО, игры и прочее. Это чего-то стоит?

Qt - это не расширения языка, это всего навсего GUI библиотека, ничего более. И всётаки хотелось бы услышать о костылях в С\С++\Qt о который вы говорили ранее.

Без инструментальной базы все вышеперечисленные "преимущетва" - ничто. Разработали крупное приложение и что далее? Отладчик сырой, а профилировщик?  Ктате, если ли профилировщик в наличии?

Вот почитайте про новый стандарт, может будите не так критичны к С++:

Новый стандарт C++: C++09 (http://forum.sources.ru/index.php?showtopic=190375&view=showall)

Стандартная библиотека C++09 (http://forum.sources.ru/index.php?showtopic=190375&st=15&#entry1601275)

>> Ненужно. Хороший программист сам себе сборщик мусора. Это зависит от кривизны рук девелопера.
Разубеждать вас не буду. Если для вас это основной критерий кривизны рук разработчиков...
Я и сам пользуюсь эклипсом, вполне неплохо. Но собираюсь переходить на вим. когда последний раз я пробовал gdb - он не показывал строк. Очень рад что вы заинтересованы - заходите к нам на dprogramming.ru - я не большой эксперт по Ди, но ребята уж точно помогут. Язык действительно потрясающий и если нет жестких требований по использованию каких-то специфических библиотек на С++ то стоит очень и очень плотно присмотреться.

По крайней мере DMD может собирать бинарник со встроенным профилировщиком и анализатором покрытия кода. Если второй с горем пополам работает, то у первого нереальные глюки. Но valgrind никто не отменял. ;)
Хотя...я балуюсь только с эксперементальной веткой компилятора D2. Возможно, в D1 дела обстоят лучше.
По ощущениям - ничего так язык, позитивный. Только вот, к сожалению, в последнее время всё заметнее тенденция к переусложнению. Особенно выносит система констант/инвариантов. А тут ещё и immutable какой-то добавить собираются...
Ещё зарезервировано ключевое слово macro и были обещания сделать поддержку работы с AST-деревом программы посредством макросов a-la Lisp.
Вообщем, если сами разработчики язык не загубят, должно получиться неплохо...
Ну и да, документация, а точнее спецификация оставляет желать лучшего. Вроде как всё понятно, а как копнёшь по-глубже - одни вопросы. Те же спецификаторы для передаваемых параметров в функцию (in/out/inout/ref/lazy/scope), непонятные заморочки с автоматическим преобразованием к делегатам и динамическим замыканиями.

to Tonal. Что такое миксины?

+1

И ещё.
Язык молодой -> библиотек нема -> всё писать с нуля -> для коммерческой разработки не подходит.
Шарп, например, появился с фреймворком, студией и лейблом Microsoft. Итог – тысячи разработчиков, сотни книг ...

Я выделил следующие плюсы:

1. Обработка исключений (exception handling). Единый стандарт.

2. Генерация документации является единой для всех реализаций языка D.

3. Вложенные функции

4. Автоматическое управление памятью. Полезно.

5. Объявление всех функций-членов классов виртуальными.



офтоп
Как цитировать чужие сообщения?

Нажать на "цитировать". :)

А что тут позитивного? вызов виртуального метода медленее, чем не виртуального (покрайней мере в С++ так)

Mixin - примесь. Класс, единственное назначение которого реализация какой-то конкретной общей функциональности.
Пусть, например, у нас есть интерфейс и несколько классов, которые его реализуют. Причём одна из функций интерфейса во всех классах реализуется одинаково, но по каким-либо причинам мы не можем вынести эту реализацию в общий базовый класс.
Тогда можно создать класс-примесь в котором и реализовать эту функцию, а всем остальным дополнительно наследоваться и от него.

Делегаты - аналог системы сигнал-слот в Qt. Несколько устарелое явление, т.к. является частным случаем замыкания + лямбда. А лямбды и замыкания сейчас как раз входят в моду: .Net 3 и C++x0. :)

Насчёт преимуществ - как "низкоуровневый" язык он сливает С/С++ как раз из за своих "высокоуровевых" возможностей при отключении которых никаких преимуществ кроме чуть более удачного синтаксиса не остаётся. (интересно, могу я в D прицепить к структуре метод для удобства и не потерять её бинарной совместимости с С. Например With() и Height() к Rect-у который использую для работы с той же WinApi или написать для какой-нибудь структуры деструктор, кторый закроет связанный с ней файл? Могу ли поместить структуры в массив или map и напрямую отдавать ссылку на них в plain C API)

Если сравнивать с C# и Java, то интересно, получаю ли я детальный трейс при, например, вылете за границы массива? Могу ли подгрузить дополнительные модули во время работы и насколько это прозрачно для меня? Каковы возможности RTTI - можно ли по имени вызвать метод или прочитсть/записать значение поля.

Общие вопросы: насколько быстрый получается код?
Какая перспектива стандартизации?
Сколько и каких проектов делается?
Кто из крупных ИТ игроков проявляет интерес/поддержку?

П.С. Собрать бинарик с профилятором и анализатором покрытия умеет так же GCC
Intel и MSVC точно умеют с профилятором.

Ну давайте подробнее - что представляет собой вызов виртуального метода это по сути что-то похожее на *(ptr+x*y)func(). порассуждаем - для соврременных процессоров операция умножения такая уж дорогая? Это только предвапрительное суждение, компилятор D анализирует иерархию и преобразует виртуальные вызовы в обычные если в этом нет необходимости. А вот вызов слота по сигналу намного медленнее.

>>Насчёт преимуществ - как "низкоуровневый" язык он сливает С/С++ как раз из за своих "высокоуровевых" возможностей при отключении которых никаких преимуществ кроме чуть более удачного синтаксиса не остаётся.
Подробнее можно?

>>(интересно, могу я в D прицепить к структуре метод для удобства и не потерять её бинарной совместимости с С. Например With() и Height() к Rect-у который использую для работы с той же WinApi или написать для какой-нибудь структуры деструктор, кторый закроет связанный с ней файл? Могу ли поместить структуры в массив или map и напрямую отдавать ссылку на них в plain C API)

Да, структуры в D полностью совместимы с Сишными. И к ним легко можно прицепить extern (C) методы. Правда насчет конструкторов и деструкторов - D1 их не имеет, только D2.

Код по скорости мало уступает gcc, я тестов лично не проводил - но можно глянуть здесь http://shootout.alioth.debian.org/
Стандартизация - лично мне она не нужна. И то что С++ стандартизирован - нисколько не делает его лучше. Даже с точки зрения стандартов - тот же msvc отличается от gcc некоторыми деталями. В случае D - я уже упоминал - есть спецификации и ее воплощение в виде dmd. Разработчики основных компиляторов используют ее.
Насчет поддержки крупных игроков - ее нет :) По проектам - кроме опен-сорсных я сказать не могу. Но его применяют.
По этой же как раз и причине я решился делать свой "проект" на D. Чтобы одной программой на D было больше. Но надо сказать у D потрясающее комьюнити.

Объясняю подробнее.
Пусть мне нужно написать нечто низкоуровневое. Это значит, что что будет много работы с железом и plain C API.
Работая на чистом С всё это у меня есть, но хочется некоторых удобств.
Что мне даёт тут С++?
У меня остаётся всё что есть в С, но появляются дополнительные нехилые удовства, например:
Я могу наследоваться от существующих plain C структур и добавить в наследник невиртуальные функции, конструктор/деструктор, перегрузить, операторы, написать шаблоны функций и классов и работать уже с такими вот навороченными объектами. При этом не утеряв бинарную совместимость, т.е. те же экземпляры я скармливаю железке и plain C API без каких-либо преобразований.
Тут утверждается что D низкоуровневый и что D круче С++ - вот и давайте сравнивать их "низкоуровневые" возможности.
Всякие виртуальности, GC и исключения тут идут лесом так как противоречат бинарной совместимости и временнЫм характеристикам.
А вот множественное наследование - вполне себе канает, т.к. не вносит оверхеда. :)

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

Тут ещё подумалось, что в этом флейме мы как-то упустили алголообразных - Pascal, Ada, Modula, Oberon.
А там есть довольно интересные нароботки - например Ada давно имеет и шаблоны и классы и исключения и сборку мусора и пакетную систему. Умеет компилятся в натив. Имеет встроенную многозадачность.
Поищи в истории - тут был как-то кадр который делал к ней биндинг. :)
Или связка Modula + Oberon используется для создания операционок Modula на низком уровне, Oberon для среднего и дальше.
Ну а в Pascal славные ребята из багланда добавили в структуры методы и перегрузку операций. А их наследники теперь ещё и шаблоны (генерики) и при этом компилят в натив. :)

П.С. Написание биндинга D к Qt несомненно будет для D очень серьёзным плюсом. :)

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

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


Кстати в треде по биндингу некоторые товарищи считают что дельфи - гамно. Приятно что не все так думают :)

А Вот из практики: профилировал я как-то одну прогу, и оказалось, что изрядно тормозит сортировка массива.
Причём массив вроде был не большой ~2-5 тысяч элементов, и сортировка была быстрая...
Но - в массиве были умные указатели на COM объекты. Т.е вся работа с ними делалась через виртуальные функции, т.е. можешь посчитать, сколько приходилось на тупой swap - а их довольно много при быстрой сортировке...
Когда это до меня дошло выход был найден тут же: создал массив структур, которые содержали только ключ сортировки и номер в исходном массиве, отсортировал его, после чего переставил элементы в исходном массиве. :)

Хотя было это лет 10 назад и сейчас машинки стали несколько быстрее, но объёмы данных тоже изрядно выросли. Так что история, как мне кажется, не потеряла актуальности. :)

В С++ не нужно ничего никуда копировать - ты просто инклюдишь эти хедеры.
Совместимые с plain C структуры есть практически во всех языках: Pascal, VB, Python, Hascell.
Какие из них на этом основании можно назвать "низкоуровневыми"?
Но только в С++ с ними можно прозрачно работать - наследоваться, добавлять методы, использовать в шаблонах без необходимости дополнительной конвертации.
Т.е. ещё раз повторяю вопрос: В чём преимущества именно "низкоуровневости" D по сравнению с С++?
Все фишечки С++ которые я описал дают серьёзный выигрыш в производительности программиста практически не давая оверхеда при выполнении.
Что тут может предложить D?
Если нечего - то и сравнивать его нужно с теми же Pascal, Ada, C#, Java.
И не говорить про какую-то абстрактную "низкоуровневость". :)

Привычки. :)

Скажу из опыта, что если в gcc (как минимум версия 4.1.2) для C кода включить профилировщик, так же можно наблюдать нереальные глюки. D в этом смысле не одинок :).

Я бы не сказал что вызовы st.processStruct() по сравнению с processStruct(st) дают серьезный выйгрыш в производительности. Также как и конвертация хидеров(которую можно проводить автоматически ;) ) А то что нельзя наследоваться - еще раз повторюсь - я бы в этом случае предпочел композицию и обернул в класс(не только в D но и С++) - а уже классы дают гораздо больше возможностей и в конечном итоге к повышению производительности:
Это занимает много времени?

Хотя конечно тот же самый OO враппер гтк для С++ конечно проще было писать, чем для D. С этой точки зрения не спорю - С++ удобнее..

Смотри выделенное.

Это занимает время и раздувает код.
Во всех методах Wrapper-а тебе нужно указать префикс struct...
Во всех системных вызовах где будут использоваться экземпляры Wrapper нужно явно преобразовывать туда и обратно.
Для случая наследования в С++ этого делать не надо - т.е. очивидный выигрыш при написании и сопровождении кода.
Кто ближе к "низкому" уровню?
На чём писать такой код проще?
Какой код проще поддаётся оптимизации - с промежуточными действиями или без оных?
Какие именно возможности дают классы обёртки к "повышению производительности в конечном итоге"?

Отож. :)

Давайте подробнее. Использование виртуальных функций несет за собой несколько побочных эффектов — увеличивается размер класса за счет таблицы vtable, увеличивается время вызова виртуальных функций. Объект каждого класса, имеющего виртуальные функции содержит скрытый от программиста указатель на так называемую таблицу виртуальных функций своего класса. В свою очередь, таблица виртуальных функций содержит указатели на конкретные реализации функций для заданного класса. Таким, образом, понятно, что вызов виртуальной функции требует накладных расходов, а именно: одно дополнительное обращение к памяти, для извлечения элемента таблицы виртуальных функций.

Для примера рассмотрим функцию класса, вычисляющую, например, определитель квадратной матрицы, что в лучшем случае выполняется за O(n*n*n) операций, где n - размерность матрицы. То есть, например, для матрицы размерности 5, это уже как минимум 125 обращений к памяти (а в действительности, больше). Соответственно издержки от объявления этой функции виртуальной составляют менее 1%. Про мат. вычисления уже говорил выше Tonal.

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

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

Вы так и не разъяснили какой выйгрыш в производительности дает st.processStruct() по сравнению с processStruct(st) . Честно - не пойму.
В общем и целом я понял что Вы имеете в виду, но согласитесь  - D предлагая существенно более высокий уровень удобства не теряет связи с системой. Не бывает универсальных языков. Если работать с системой преимущественно, писать драйверы для ОС или еще что-то следует предпочесть основной язык системы. В случае же с D - это просто дополнительная возможность - в случае необходимости легко получить доступ к системе.

Первоклассник: «Папа, а как пишется цифра восемь?»
Отец: «Возьми знак бесконечности и поверни на пи пополам.»

Про Ди. Рассматривать язык отдельно не имеет смысла. 90% (а то и больше) функционала прикладных программ это библиотеки. Сейчас я пишу на cpp+Qt и у меня есть замечательный классы для строк, массивов, словарей и т.д. Раньше писал с MFC. И там тоже всё было. И отсутствие типа «строка» в языке мне до лампочки. Плюс к этому – функционал QString, наверное, побольше чем у строк Ди.
Про Qt. Писали что Qt – костыли. Согласен. Но костыли-скороходы.

ребят, хватит уже про "костыли", а?
std:: - стандартные расширения языка; boost:: - расширения, по тем или иным причинам не попавшие (пока) в "стандартные" - почитайте историю проекта буст...
Qt проводит ряд врапперов над этими расширениями, к тому же буст в кутэ используется крайне редко (за исключением вэбкита, который таскает с собой собственный ряд врапперов)
как можно расширения называть "костылями"? как можно QVector называть "костылём"? чем не нравится qforeach?

Си изначально был задуман как язык с минимальным встроенным функционалом, где все необходимые расширения будут подключаться по мере надобности, а при таком подходе расширения критически необходимы...
возьмём примера ради работу со строками - имеется стандартное расширение std::string, НО никто не заставляет программиста использовать именно это расширение - вы вполне можете написать что-то более производительное или лучше отвечающее требованиям; также отпадает проблема с кодированием и структурированием строк (а вдруг ещё лет через 10 придумают utf-88 и 555-терминантные строки?). т.о. Си изначально не зависит от прихотей моды и тенденций - всегда можно написать необходимую реализацию и использовать её в качестве основной реализации строк (хэша, вектора и т.п.)

единственное, с чем соглашусь - include (а в особенности, include/include_next) иногда бывает неудобным...часто из-за того, что человеку свойственно что-то забывать...например, гварды :)
но такие "детские болезни" легко излечиваются выбором удобной среды разработки.

С ньюсгруп на digitalmars.com - How does D improve design practices over C++?
- Unit checking
- Design by contract
- Invariant checks
- Stronger const
- Modules
- Garbage collection
- No automatic copy constructor
- More restrictive operators
- Delegates (Specifically, encouraging there use by making them simple to use)
- Specific constructs such as Interfaces
- More restrictive casting
- No C style Macros
- Overload sets which prevent function call hijacking
- Nested functions
- Structs with value semantics, Classes with reference semantics
- Ability to move (bitcopy) a struct without invoking construction
- Alias parameters to templates
- Compile time function evaluation
- Function, array, and struct literals
- String mixins
- In, reference, and out function parameters
- Lazy function parameters
- Standardized way of doing conditional compilation
- Standardized way of debug conditionals
- Warnings on implicit casts that lose bits
- No uninitialized data
- User defined default initializers for typedefs and fields
- Template constraints
- The override keyword helps you make sure really overriding something.
- encourages less frequent use of pointers
- enforcing better encapsulation.  Things can be shared only in modules

Я про moc. Это уже сложно назвать расширением языка.

какое отношение moc имеет к языку?
MetaObject Compiler - где хоть слово про язык? может и qscript - костыль к языку?

Самое прямое отношение. В С++ нет ключевых слов slot и signal. А moc - это костыль, если бы имелись делегаты - необходимость в нем бы отпала.

Если бы немного почитали доки по Qt то нашли бы объяснение существованию moc.
Систему слот-сигнал можно реализовать без кодогенератора при помощи шаблонов (пример boost::signals), правда там тоже есть свои нюансы

emit/slots/signals это макросы, а не ключевые слова, если посмотреть по хедерам можно найти определения
а если прописать в .pro файл "CONFIG += no_keywords" то и их не будет (будут "правильно" именованные макросы).

Ньюансы это мягко сказано. Наверняка вы смотрели хоть раз исходники буста. И как впечатления?  ;D Сама элегантность. Никто не говорит что что-то невозможно сделать на С++. Просто для подавляющего большинства задач на сегодня есть средства намного превосходящие его.

да что за безосновательно засирание? исходя из такой логики, я тоже могу сказать, что D - костыль к C!
moc - костыль...костыль к чему? делегаты в д позволяют вызывать методы по имени класса? а сконструировать сущность класса по его имени можно через делегат? а вызвать статический слот класса, не имеющего ещё ни одной сущности, можно?
всё ещё думаешь, что moc имеет "Самое прямое отношение" к Си?!

кстати, может и QTranslator - костыль? почему бы языку не иметь встроенной возможности интернационализировать литералы?!

один из факторов, определивших судьу буст как отдельного проекта...

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

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

Присоединияюсь к вопросу Константина (на который ещё нет ответа):

С чего взяли, что moc это костыль? И костыль к чему?

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

Но не кастыль же )))) Нужно как-то отперделиться с понятиями. А то по-вашему получается - все что не относиться к языку как таковому - кастыли. STL - кастыль, Phobos и Tango - тоже кастыли (а это ваще обсурд! зачем нужны две стандартные библиотеки?) Это бы я и назвал кастылем:


Это не костыль?


Позволю себе заметить вы бы тоже )))

Кстате, а D дружит с 64 битной архитектурой? Прочитал что есть поддержка 16? и 32 бит архитектуры. Про 64 ничего не сказано.

Только С и С++ не имеют нормальной поддержки строк среди популярных языков программирования. Это хорошо или плохо?
Насчет фобоса и танго - здесь немного другая ситуация. Фобос - это стандартная библиотека от автора языка, но она по возможностям достаточно скудная. Как альтернатива сообществом разрабатывается гораздо более богатая и функцинальная tango. Tangobos - костыль, но для тех кто переходит с фобоса на танго для временной совместимости с существующим кодом. Но и он скоро уйдет в прошлое, так как обе библиотеки будут использовать общее runtime ядро. Назначение библиотек разное немного. фобос это минималистичный вариант, созданный скорее для обкатки новых возможностей. D следует использовать с танго.
Да и взять С++ фобос и танго - это то же самое что и std:: и QtCore. Qt это намного больше чем ГУИ библиотека. Это самодостаточная платформа.
Да и смысл этой ветки вообще не понятен. Те кто заинтересовались - посмотрят и сделают выбор. Многим не подойдет Ди из-за малой степени развития инфраструктуры, в отличие от С++ да и справедливо, что существующие проекты никто не будет переписывать. Я начал писать свой проект с нуля, поэтому я могу выбирать. Использовать С++ большой необходимости у меня нету.
64 битная архитектура компилятором dmd не поддерживается и врядли когда-нибудь будет. компилятор в llvm будет иметь эту поддержку(для линукса практически доделали, для win - в процессе).

В данный момент компиляторы D сливают компиляторам С++. 32 уже устаревшая платформа (про 16 молчу).

млять, ну, решили ведь уже, что std:: - не костыль! к чему опять про строки?
я хочу увидеть хоть один сложный тип данных с Си - покажите мне его! так почему строки должны быть исключением?! есть char* - чем не строка? ах, работать неудобно...тогда подключай std::string. или тоже неудобно?

Я так понял вы полагаетесь на стандартные библиотеки. А без стандартных библиотек D юзабелен? Какой функционал предоставляют тандартные библиотеки?

Как и в других нормальных языках - функционал не относящийся к базовым возможностям языка. За подробностями идите в dsource.org/projects/tango

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

Насчет устаревания 32бит - 64битные ОС далеко не подавляющее большинство сейчас. 64 битный компилятор D уже на подходе. А то что сливает - разница совсем небольшая, и это разница между dmd и gcc. Надо сравнивать с llvm D - это уже совсем другой разговор будет.

asm

Так что-же вы на асме то не пишете? Почему перешли с асма на С? По той же причине и С++ должен отправиться на свалку истории.

Не настолько Ди (прогрессивен?) лучше С, чем С лучше асма.
Лучше!=(АСМ==Отстой)

Асм не отстой потому что занимает четкую нишу. А С++ лезет туда, куда ему уже не следует лезть - где есть более удачные альтернативы. Насчет преимуществ Ди - я скинул еще подборку в конце 3 страницы. Думаю внушительный список.

Если бы от Си до Ди было так же как от Асм до Си, то без вопроса все бы перебежали. Я вот это хотел сказать, если непонятно выразился.

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


Это весьма расплывчатая фраза. Какая ориентировочная дата выхода? На подходе он может быть неодин год.


Когда я употребил слово сливает, я имел ввиду что копиль D не генерит 64 код.

И в каких местах приемужетво D будет очевиднее С++?


Список нововведений мал и смысла от этих нововведений также мало. В списке нет очень весомых фактов для перехода на него

Moc, по сути, есть предкомпилятор. По кучи зарезервированных слов он генерит С++ код. Эти слова являются макросами С++ только для того, что бы нормально компилировался исходный файл. Мето-информация приделана к С++. И приделана, так чтоб ей можно пользоваться средствами C++. Moc это не библиотека, написанная на самом С++. Это внешняя программа.
З.Ы. Костыль – слово не подходящее, даже оскорбительное по отношению С++. Но его ввёл в нашу беседу не я.

Из ассистанта:

А я что не так сказал?

Дык, а что я вам сказал? о_О

и это ещё из старой документации. в 4.5 метаобъектная система Qt значительно расширится.
кстати, часто ли разработчики расширяют функционал костылей? :)

Информация взята из последнего релиза (4.4.3) :)

я понял,
но и мы же здесь говорим не только о стабильном d, который d1... :)

гм...забыл совсем )
а не пишу я на асме, т.к. плюсы много удобнее при тех же (почти) размерах/производительности бинарей + не собираюсь писать грфический фрэймворк и великое множество оболочек на асме.
я не страдаю из-за отсутствия строк и ассоциативных массивов непосредственно в синтаксисе языка...и считать это недостатком реализации языка как такового - полнейший бред!
механизмы сигнал-слот в базовой реализации также НЕ нужны, как НЕ нужны и встроенный сборщик мусора, и "умные" указатели вместо обычных!
если мне потребуются "умные" указатели, я подключу соответствующее расширение (или напишу свою реализацию); если (вдруг) мне потребуется сборщик мусора, я соберу свой проект со сторонним...к тому же, valgrind ещё никто не запрещал.
поэтому я и пишу на плюсах, а не на асме, не на паскале, и не на жабе-диезе-д...

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

сборщик мусора ненужен :)

Сборщик мусора будет прививать криворукость программерам.
Зачем писать код изначально правильно? зачем освобождать память? Ведь все может сделать сборщик мусора ))) Да, пусть нам потребуеться намного больше памяти и мощи копма для этого, но зато мы небудем париться с освобождением памяти.

Вот такой подход развивают всякие сборщики мусора.

Этот спор абсолютно бессмыслен после таких заявлений. Какой же список нововведений должен быть, чтобы превосходить С++? Наверное потому что вы считаете плюсы идеальным языком программирования. Что ж разубеждать я вас не собираюсь.

и напоследок - отличный коммент на сегодняшнюю новость о принятии C++ 0x - "Дизайн кожанной плётки для мазохистов приобрело окончательный вид..."

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

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

Пример сказанному:
Подобное на языке "X"

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

Что касается сборщиков мусора. так это ппц задача и она не решаема просто ибо не бывает просто. И хорошо когда есть возможность этот процесс контролировать... вот даже C# дает такую возможность, работать напрямую с указателем.

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

Небось писали map<type1, map<type2, type3>>?

Вроде пробел надо добавить в конце, не ">>" а "> >"

Экий флеймеще накатали пока я спал... :)

Я говорил про выигрыш в производительности труда программиста.
Если не понятно, какой выигрыш дают классы с методами по сравнению со структурами и свободными функциями то не ясно зачем использовать C++, C#, Java, D вместо простого С. :)
А в С++ классы, в отличии от остальных перечисленных, предоставляя выигрыш в производительности труда, ещё и не дают оверхеда при выполнении.

Да я не спорю, что есть некоторые улучшения по сравнению с С++.
Но надо представлять себе и цену этих улучшений - отказ от совместимости с С и С++ и накладные расходы на их поддержку во время выполнения.
А это значит и невозможность использования этих "улучшений" на "низком" уровне.
Отсюда приходим к выводу, что D на "низком" уровне никаких преимуществ по сравнению с С++ не имеет и даже наоборот - имеет описанные недостатки.

Значит D нужно сравнивать с остальными "улучшателями" С++, как то Java и C#. :)

Да и вообще писать язык который всего лишь "устраняет недостатки" существующего как то не очень интересно.
Во первых таких и так уже есть довольно много: Java, C#, MC++, да и разных расширений в каждом компиляторе навалом. Т.е. почему мне с С++ нужно переходить именно на D а не на другой "улучшатель" не вполне ясно.
Во вторых - люди, которые плотно работают на базовом языке, все эти "грабли" давно научились обходить на автомате, написано много литературы о том, что и как делать, большое сообщество, которое с большой скоростью сможет помоць с проблемным кодом и объяснить как нужно "правильно жить". :)
И в третьих - это значит что по существу ничего новое не создаётся - т.е. при переходе на D не получаешь "кардинальных" преимуществ повышающих производительность хотя бы на порядок которые бы могли оправдать подобный переход.
А вот скажем при переходе на Python, Erlang, Haskell - получеш.
Соответственно, куда имеет смысл переходить? :)

Другое дело, если у кого-то нет опыта, нет кода который нужно поддерживать, и нет критериев "лучшести" окромя простоты синтаксиса и доступности учебников.
Тогда естественно использовать более простые и понятные языки - вот здесь D, Java, C#, MC++ вполне конкурентноспособны.
Как раз за счёт того, что поначалу можно плюнуть на детальные учебники а отсылать к аналогам по более раскрученному языку просто отмечая небольшие различия. :)

П.С. С моей точки зрения и среды и отладчики - довольно вторичные штуки. И выигрыша на порядки даже самая навороченная среда просто не даст в лучшем случае в 1,5 - 2 раза а то и на какие-нибудь проценты. :)

запись вида:

К примеру я потратил в сумме часов 10 на вылавливание двух простеньких ошибок пользуясь отладчиком Visual Studio:
1) В цепочке вызовов передается QImage и в конце в него должен рендерится текст. На выходе никакого текста нет. Оказалось в цепочке в одном месте параметр передавался просто как "QImage image" вместо "QImage &image". Библиотека просто сделала копию всего Image а потом удалила вместе со всем отрисованным. Ну нафига так делать? Неявное копирование просто зло для подобных объектов.
2) В программе где то у строки вылезает Assert на обращение к символу по индексу за пределами длины строки. Стек вызовов при остановке не показывается. Может я чего то не понимаю в отладчике, но почему он не отображается? Сидел проверял все возможные места обращения к строке посимвольно пока не нашел.

Ну вот не понимаю я как возможно быстро в C++ такие ошибки отладить, Visual Studio вроде лучший инструмент для этих целей и все равно проблема.
На C# где я программировал раньше 1 ошибка просто невозможна, 2-я локализовалась бы моментально по стеку вызовов.

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

2 Detonator:

1) Это невнимательность, а не недостаток языка
2) Нет опыта отладки. Когда выскакивает ассерт, нажмите кнопку Продолжить, получите стек вызовов

Когда ты писАл QImage image, вместо QImage &image, ты о чем думал? Почему ты считаешь это проблемой C++, а не проблемой своей квалификации?

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

BRE, разумеется ты никогда подобных ошибок не допускаешь, так научи меня глупого как останавливать отладчик в местах Assert'ов чтобы стек вызовов сохранялся.

[qoute]QImage image, вместо QImage &image, ты о чем думал? Почему ты считаешь это проблемой C++[/qoute]

В данном случае я считаю что это проблема библиотеки а не языка, QImage должен себя вести как некопируемый объект, копирование делать только специальной функцией. Вот например у QScriptValue все сделано правильно, результат ожидаем, у QString/QByteArray тоже.

ну если это Q_ASSERT то можно ловить вызов qFatal

Честно, не знаю как там под вендой, но под линуксом у меня с этим проблем никогда не возникало.

Не понял что там про некопируемые объекты... В C++ (! не Qt) когда пишешь: void megafunc( Type param ), в теле функции имеем копию param - по-любому. Почитай книги...

вроде э уже ответили на этот вопрос: кнопку "Continue" в диалоге ассерта нажать надо и будет вам стек вызовов.
см. пост pastor'a

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

Никакого копирования QImage непроисходит. QImage - это шаровый класс. Происходит лишь увеличение счетчика ссылок на данные. ЛДишь при попытке модификации данных происходит копирование.

Более того, Qt здесь абсолютно непричем. Передача по значению, по ссылке, через указатель - это специфика языка, а не библиотеки.

Я так понимаю это мне адресовано было. Могу ответить. Я почти полностью изучил 1000 страничную книгу по плюсам, плюс 2 книги Мейерса(половина советов была о том как нельзя писать на С++). Я умею управлять памятью и подчищать ее за собой. В Ди к вашему сведению при необходимости я также пользуюсь malloc.
По Вашему значит программисты на python или hascell ничего не соображают в программировании? Да пишите тогда на асме - будете намного больше понимать в работе компьютера. Или в машинных кодах. Не хочу Вас обидеть, но то что вы написали про кирпичи полный бред. Александреску, если вы слышали о его книгах(для меня они пока слишком сложные) наверное ничего не понимает в строительстве домов(программировании), что бросил С++ и разрабатывает/использует D.

Я не писАл это обращаясь лично к тебе. И сразу предупредил, что не хочу никого обидеть...
В последнее время на форуме было  несколько обсуждений так называемой "кривости" языка С/С++, кто-то не понимал указателей и ссылок, кто-то не понимал множественного наследования и ручного управления памятью. Люди место того, чтобы разобраться со всеми тонкостями языка, говорили просто - С/С++ это фигня. Вот этот пример и описывает такое отношение к делу.

Вот ключевой момент. Разработка нового языка это ИССЛЕДОВАНИЕ. В результате таких исследований появляются новые конструкции, которые могут заимствоваться в других языках, но это и те вещи которые показывают свою неудачность. Это именно ИССЛЕДОВАНИЕ. Пройдет еще много лет, пока этот язык станет промышленным, когда на него будут разработаны стандарты и им можно будет спокойно пользоваться в больших проектах. Причем к этому моменту он может сильно измениться и не в приятную для тебя сторону.  ;)

Ага ... а кирпичи все разные, и круглые тоже :)
Еще точнее - Египетские пирамиды, а наверху ф-я int main() :)

с уважением ...

pastor
Мне очень хотелось бы услышать от Вас, какими качествами для Вас обладает идеальный ЯП? Перечислите пожалуйста, мне интересно.

Меня пволне устраивает С++

Вот не получаю, и при Continue, и при Break стек пустой, вернее в нем одна строка - какая-то даже не qt-шная dll (сейчас воспроизвести и точно сказать не могу). Потому мне и кажется что то-то при компилировании или в настройказх отладчика не так указано.

А поток один?

Критерии выбора языка:
- время на изучение (например, с++ я знаю – время 0);
- наличие хорошей IDE;
- наличие библиотек для поставленных задач;
- количество людей использующих язык;
- выразительность, т.е. возможность использовать разные парадигмы;
- платформы;
- перспективы языка.
Порядок выбирается в зависимости от задачи.

А могуч С++, тем что там нет сборщика мусора, а если он мне понадобится, я могу воспользоваться сторонним или написать свой.
Тем, что управлением памятью я могу управлять так, как считаю нужным и для разных объектов могу сделать разные механизмы.
Тем, что когда я достаю значение по указателю, то достается значение из ячейки памяти, без кучи дополнительных проверок, а все ли там правильно. Если мне это потребуется я могу это сделать сам, так как мне нужно или использовать готовое решение.
Тем, что если мне нужны строки, я могу использовать те, которые мне нужны. (char *, std::string, QString, ...).
И этот список можно продолжать и продолжать.
В С/С++ все решаю я, так как мне надо.

А могуч D, тем что там есть сборщик мусора, а если мне понадобится, я могу воспользоваться ручным выделением памяти в критичных местах, не тратя время во всех остальных случаях на поиски утечек. А могу вообще отключить его(только зачем?) Тем, что управлением памятью я могу управлять так, как считаю нужным и для разных объектов могу сделать разные механизмы. Тем, что когда я достаю значение по указателю, то достается значение из ячейки памяти, без кучи дополнительных проверок, а все ли там правильно. Если мне это потребуется я могу это сделать сам, так как мне нужно или использовать готовое решение.
Если мне нужны строки, я не заморачиваюсь что Сишная библиотека использует char *, С++ std::string а Qt - QString, я просто использую строки.

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

Как в С++.

Как в С++.

Какой функционал у строк в D? Он хоть немного приближается к QString? Если нет, а хочется, подключать стороннии решения?


В чем ключевые преимущества перед С++?

Плюсы язык слишком высокого уровня. Надо напрягать моск ассемблером.

Ну могу ответить. Вопрос был вроде - можно ли методы класса вызывать по имени в D. Можно. И если постараться - то все, а не только обработанные специальным препроцессором(я про moc). Только вопрос - зачем. Все методы-слоты известны на этапе компиляции, динамически добавлять методы нельзя. Зачем эта рюшечка в виде invokeMethod() ?
Можно также создавать объекты по имени класса, это реализуется доп-библиотекой и работает без доступа к исходному коду.

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

Итак, вот программа на C++, ничего особо осмысленного не делающая, но, при этом, иллюстрирующая некоторые весьма раздражающие особенности этого языка (комментарии вида /* N */ — сноски, поясняются ниже):

C++ (Qt)
#include <stdio.h>
 
class base
{
private:
	int i, j;
 
	void prn(int t)
	{
		printf("%s: %d \n", pref(), t); /* 1 */
	}
 
protected:
	void prn_i() { prn(i); }
	void prn_j() { prn(j); }
 
public:
	base(int a, int b) : i(a), j(b) {}   /* 2 */
	base(int c) : i(c+1), j(c+2) {}   /* 2 */
 
	virtual const char* pref()
	{
		return "bs";
	}
};
 
 
class iface   /* 4 */
{
public:
 
	virtual void foo() = 0;
	virtual void bar() = 0;
	void all()
	{
		foo();
		bar();
	}
};
 
 
class impl1 : public base, public iface
{
public: // base
	impl1(int a, int b) : base(a, b) {}   /* 3 */
	impl1(int c) : base(c) {}   /* 3 */
 
	virtual const char* pref()
	{
		return "i1";
	}
 
public: // iface   /* 4 */
	virtual void foo() { prn_i(); } 
	virtual void bar() { prn_j(); } 
};
 
 
class impl2 : public base, public iface
{
public: // base
	impl2(int a, int b) : base(a, b) {}   /* 3 */
	impl2(int c) : base(c) {}   /* 3 */
 
	virtual const char* pref()
	{
		return "i2";
	}
 
public: // iface   /* 4 */
	virtual void foo() { prn_j(); } 
	virtual void bar() { prn_i(); } 
};
 
 
 
void poly(iface& i)   /* 5 */
{
	i.all();
}
 
int main()
{
	impl1 i1(10);
	impl2 i2(20);
	poly(i1);
	poly(i2);
	return 0;
}
 

Итак, что мы имеем:

/* 1 */ — ф-ция pref возвращает указатель. Предполагается, что это указатель на строку, и что она оканчивается нулем. И здесь это действительно так. Однако никто не мешает мне в производном классе написать такую реализацию pref, которая будет возвращать черт знает что. Например — NULL. С закономерным результатом, в виде падения всего этого дела. В C++ нет такой вещи, как встроенная строка...

/* 2 */ — списки инициализаторов в конструкторах. Весьма негибкий механизм. Здесь мы из-за него имеем "всего лишь" дублирование кода. В более сложных случаях нам, например, могли бы потребоваться некие достаточно сложные промежуточные вычисления — и мы не смогли бы их осуществить без отказа от использования этих списков. Если инициализируется достаточно сложный объект — такой отказ неприемлем...

/* 3 */ — если мы хотим, чтобы производный класс сохранял свой интерфейс, мы вынуждены дублировать в нем все конструкторы базового класса. Избежать дублирования кода невозможно.

/* 4 */ — множественное наследование. Сама по себе вещь может и хорошая, но реализована в C++ совершенно ужасным образом. Чего стоит один только механизм вызова конструктора у виртуальных базовых классов, когда мы вынуждены их вызывать на протяжении всей иерархии! Про многочисленные неоднозначности, которые регулярно возникают в результате использования всего этого дела, вообще молчу... (Здесь, впрочем, всего этого нет — я, все-таки, хотел, чтобы программа компилировалась...)

/* 5 */ — объект передается по ссылке. И это надо указывать явно. Пожалуй это больше плюс, чем минус. По крайней мере, ясно видно, где что. (Да, знаю, что здесь нужен const... Но для примера и так сойдет.)


А теперь посмотрим, как это будет на D:

D
import std.stdio;
 
class base
{
private:
	int i, j;
 
	void prn(int t)
	{
		printf("%*s: %d \n", pref(), t);  /* 1 */
	}
 
protected:
	void prn_i() { prn(i); }
	void prn_j() { prn(j); }
 
public:
	this(int a, int b)   /* 2 */ 
	{
		i = a;
		j = b;
	}
	this(int c)   /* 2 */
	{
		this(c+1, c+2);
	}
 
	char[] pref()
	{
		return "bs";
	}
}
 
 
interface iface   /* 4 */
{
	void foo();
	void bar();
	void all();
 
	template iface_mix()
	{
		void all()
		{
			foo();
			bar();
		}
	}
}
 
 
class impl1 : base, iface
{
	// base:
	this(int a, int b) { super(a,b); }   /* 3 */
	this(int c) { super(c); }   /* 3 */
 
	char[] pref()
	{
		return "i1";
	}
 
	// iface   /* 4 */
	mixin iface_mix;
 
	void foo() { prn_i(); } 
	void bar() { prn_j(); } 
}
 
 
class impl2 : base, iface
{
	// base:
	this(int a, int b) { super(a,b); }   /* 3 */
	this(int c) { super(c); }   /* 3 */
 
	char[] pref()
	{
		return "i2";
	}
 
	// iface   /* 4 */
	mixin iface_mix;
 
	void foo() { prn_j(); } 
	void bar() { prn_i(); } 
}
 
 
void poly(iface i)   /* 5 */
{
	i.all();
}
 
int main()
{
	impl1 i1 = new impl1(10);   /* 6 */
	impl2 i2 = new impl2(20);   /* 6 */
	poly(i1);
	poly(i2);
	return 0;
}
 

Итак, что изменилось и что добавилось:

/* 1 */ — ф-ция pref возвращает именно строку. Заданного размера. Завершающий ноль не нужен. Если я в каком-то из производных классов не стану ее инициализировать — поле размера станет нулем и printf не выведет на ее месте ничего.

/* 2 */ — списки инициализаторов отменены. Мы инициализируем значения в конструкторах путем обычного присваивания. Более того, мы можем вызывать конструкторы друг из друга, избегая, таким образом дублирования кода.

/* 3 */ — проблема не решена. Мы по-прежнему вынуждены дублировать здесь код. Может быть, конечно, дело в том, что я не слишком хорошо знаю этот язык, но способа избежать этого я не вижу...  :(

/* 4 */ — от проблем, вызванных множественным наследованием, здесь решили избавится радикально: множественное наследование запрещено. D, в этом, увы, не одинок. Печальный опыт кривой реализации этой фичи в C++ еще долго будет давать о себе знать... Но D предлагает на замену такой механизм, как миксины. И разрешает использовать их внутри интерфейсов. Это позволяет реализовать почти все, что можно реализовать с помощью множественного наследования, избегая, вроде бы, граблей последнего. Здесь только одна проблема: при таком подходе все миксины будут разворачиваются в область видимости имплементации. Соответственно, если миксинов много — опять-таки может возникнуть конфликт имен. И я не уверен, что разрешить его будет легче, чем в C++...

/* 5 */ — объект класса передается по ссылке. Всегда. Если нужно передавать по значению — это должна быть структура, а не класс. Я не уверен, что это хорошо. Конечно, в 99% процентах случаев нам требуется именно такое поведение, но если потребуется обратное — у нас проблемы...

/* 6 */ — а вот и кое-что новое. Сборка мусора. Палочка о двух концах. Конечно, это удобно. Очень удобно. Но, с другой стороны — это сильные тормоза и потенциальный memory leak из-за "мертвых ссылок". Лучше было бы сделать эту фичу более опциональной...


И того. Что мы имеем только из одного этого примера? Из 4 продемонстрированных проблем C++, 2 решены, 1 решена частично, 1 не решена вообще. Плюс появилось 2 новые фичи, и по крайней мере 1 из них вполне может создать новые проблемы.

Конечно, это очень небольшая часть языка. Я не коснулся шаблонов (где в C++ очень много проблем, а в D  — изменений). Я не рассматривал такие нововведения, как поддержка многопоточности, контрактное программирование, отложенные вычисления... Я не упомянул о других проблемах (например, неоднозначность выражений, подобных i=i++ + ++i в D никуда не делась...).

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


Вывод: Четверка. С минусом. И не более.
Во всяком случае — пока...

1. Из функции pref нужно возвращать std::string или константную ссылку на неё char* следует оставлять только для связи с внешним API.

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

3. Конструкторы относятся к ненаследуемому интерфейсу класса, т.к. при его вызове, ты всё равно явно указываешь имя класса, и параметры конструктора.
Единственное исключение: наследования шаблона от своего параметра. В этом случае мы можем просто не знать сигнатуру конструктора. Хотя есть некоторые приёмы, позволяющие обойти это ограничение.

4. Множественное наследование реализовано в С++ в наиболее общем виде из всех мне известных.
В D поддерживаются 2 ограниченных способа - наследование интерфейсов и миксины.
В любом случае - множественное наследование само по себе довольно сложная вещь, поэтому даже при применении этих ограниченных способов можно изрядно напутать.
Так что тут сложность самой концепции. :)

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

Вывод: D просто небольшое "подсахаривание" С++ и его знаменитых наследников Java и C# принципиально нового ничего нет. Переносимости, по сравнению с С++ или Java нет. Библиотек почти нет. Документации нормальной нет. Стандарта или твёрдого плана развития нет. Вакансий нет.
Для нормально знающего С++ смысла переходить нет - слишком мало плюсов.
Для новичка следует выбирать именно из Java, C#, D ориентируясь на перспективы роста и развития.

Ну а если поиграться - язычёк прикольный. :)

Очень даже наоборот, очень близок к ассемблеру.
Читай внимательно QAxObject, там всё написано. И добавление динамического слота и вызовы.

...и тащить с собой STL и весь ворох связанных с ней проблем.
Не хотел я затрагивать тему — уж больно необъятная... Если вкратце — то грабли, связанные с этой библиотекой, можно разбить на две категории:

1. Обобщенные проблемы обобщенного программирования в C++. Когда в этом языке появились шаблоны — никто не планировал, что их будут использовать для чего-то, более сложного, чем элементарные реализации контейнеров. В результате — никто и не позаботился, чтобы они были для этого приспособлены. Как результат — их использование для подобных целей получилось, мягко говоря, не слишком удобным. Я хорошо помню, как Страуструп в своей книге ругался на strcat и strcpy, гордо заявляя при этом, что теперь для этих целей можно использовать '+' и '='. И что мы получили в результате? Совершенно нечитабельные конструкции из адаптеров, алгоритмов, биндлеров, хрен знает чего еще, по сравнению с которыми все содержимое cstring — просто детский лепет...

2. Вторая категория проблем проистекает из того, что процедуре стандартизации была подвергнута совершенно сырая и неопробованная технология. Думаю, не ошибусь, если скажу, что во время разработки стандарта прототип STL находился, в лучшем случае, на стадии β-тестирования (а скорее всего — α). Думаю, все здесь знают, насколько часто приходится менять интерфейсы библиотек на начальной стадии их разработки. И все помнят, как сильно изменился, скажем, интерфейс Qt при переходе с 3 на 4. STL же оказалась лишена возможности подобного развития. Сырую библиотеку отлили в бетоне. И вот уже больше десятка лет мы вынуждены терпеть ее грабли, косяки, непродуманный интерфейс и отсутствие элементарных удобств.

К чему я все это говорю? А к тому, что, в результате всего этого, многие программисты (включая вашего покорного слугу) STL, прямо скажем, недолюбливают. И стараются, насколько это возможно, дела с ней не иметь. В результате, отказавшись от char*, один будет юзать QString, другой — wxString, третий таки воспользуется std::string, четвертый вообще напишет какой-нибудь my::string, а пятый будет думать, как со всей этой херней взлететь заставить их всех ужиться в одном проекте...

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



Да, с этим примером погорячился. Но все равно — если конструкторов несколько, мы вынуждены писать список инициаторов для каждого из них. Имеем дублирование кода.


Это хорошо. Вот только когда это будет?..



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

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

C++ (Qt)
foo::foo(int x, int y) : bar(x, y) {}
 

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

C++ (Qt)
using bar::bar;
 

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


С++ не единственный язык, поддерживающий этот самый «наиболее общий вид». Полноценное множественное наследование есть, например, в перле и питоне. И там никто от связанных с ним проблем не страдает. Потому что четко определён порядок приоритета, в котором должны разрешаться связанные с этом механизмом коллизии. В C++ достаточно было бы ввести самые простые правила, например такие:

1. В случае неоднозначности вызова ф-ций членов, приоритет имеют ф-ции, принадлежащие классу, идущему первым в списке базовых классов, если в производном классе явно не определено иное путем использования директивы using.

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

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



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

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

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

Еще из языков этого уровня уровня можно вспомнить perl6, который значительно лучше их всех. У него только один недостаток: его не существует. И он появится — одному Ларри Уоллу известно...



Вот именно, что только поиграться.  :(
Когда я только наткнулся на этот язык — попробовал написать на нем одну нужную мне утилиту. Получил — из-за кривой сборки мусора, не иначе — страшные тормоза и утечки. Долго ругался, потом переписал все на C++ и спокойно пользуюсь уже несколько лет...

STL уже есть в любом компиляторе, т.к. является частью стандарта.
Так что "тащить" ничего никуда не нужно - оно уже там. :)

Как бы проблемы с шаблонами не имеют отношения к использованию std::string. :)
А совмещение (перегрузка) операторов действительно удобнее чем вызовы функций. По крайней мере в некоторых областях использования. :)

С моей точки зрения наоборот - слишком затянули, вот и появились многочисленные строки и контейнеры, которые теперь приходится согласовывать.
А был бы стандарт - все бы использовали его и пинали бы комитет чтобы добавил недостающие возможности.
Я начал использовать std::string как только она у меня появилась: borland c++ 5.0 - последний добилдеровский компилер от багланда.
И все строки от библиотек перевожу в std::string при первой возможности.
Написал некоторое количество обвязок конечно, но сейчас все выкинул, т.к. все они есть в boost-е. :)

Вспомни, что С++ позиционировался как прозрачная замена С. А это значит, что такой тип просто бы не стали использовать т.к. не очевидна реализация.
Соответственно зоопарк своих строк всё равно бы появился. :)

В будущем году примут.
Основные компиляторы уже начали реализацию.
Так что думаю, через год, а то и раньше, будем дружно плеваться. :)

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

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

П.С. Если на метопрограммирование на шаблонах смотреть не как самоцель или жупел, а как на средство уменьшения количества писанины, то опять же всё становиться на свои места.
Их нужно применять там и тогда, когда и где они нужны. :)
Не случайно в Java и C# их таки добавили. И даже в последнюю Delphi! :)
причём везде с выводом типов и возможностью метапрограммирования.
Хотя пока эти новые возможности довольно сильно уступают плюсовым, а с принятием нового стандарта отрыв ещё увеличится. :)

Ну, если вспомнить, что std::string, строго говоря, тоже шаблон...   ;)
Но вообще да, здесь мы имеем дело только со второй частью проблемы, а именно — с сильно кривым дизайном этого класса... :)


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


Кстати, да. Оба утверждения справедливы. Если бы контейнеры и строки были в языке с самого начала — как iostream — никто бы не стал пропихивать в стандарт сырую поделку товарища Степанова. И многих проблем удалось бы избежать.  :)


Угу. Я примерно тогда же... После чего очень быстро переключился на сильно другие языки, в которых такого уродства не было. И лет пять старался держаться от C++ подальше. Потом вернулся... но мнения об STL не изменил. И более того, насмотревшись разных вкусных вещей, стал относиться к самому языку гораздо более скептически.

Проблема только в том, что альтернативы ему, в своей нише, увы, нет. D на такую альтернативу, как я, к сожалению, имел возможность убедиться, не тянет.  :(



Так разве ж я против метапрограммироавния? Я очень даже за. :)
Просто речь о том, что в C++ этим инструментом крайне неудобно пользоваться. Напоминаю твою собственную цитату из соседней ветки (http://www.prog.org.ru/topic_7073_0.html), где речь как раз про это самое метопрограммирование и шла:
И под этими я готов подписаться обеими руками: насколько проще было бы писать такие вещи на C++ если бы там было... [длинный список]. И, кстати, как раз в этой области у D очень много весьма полезных нововведений, которые превращают метопрограммирование на этом языке... ну, если не в конфетку, то, во всяком случае, в нечто, весьма далекое от той... ммм... субстанции, с которой мы имеем дело в C++  :)




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

Но в перле, во всяком случае, добиться эффекта, эквивалентного виртуальному наследованию, очень легко. Вообще, хотя ООП там реализовано лишь частично (полностью — только в perl6, который неизвестно когда будет), в той части, в которой оно таки реализовано, остальным языкам следовало бы взять пример... Пожалуй, я даже приведу пример,  иллюстрирующий этот механизм. На C++, на перле, а потом, не уходить в офтопик, посмотрим, как с этим в D...

Итак, классическая схема "ромбиком", на классическом же примере — допустимые ходы шахматных фигур (слон, ладья и ферзь). Размер доски для простоты считаем бесконечным, коллизии не смотрим. Сперва — C++:

C++ (Qt)
#include <iostream>
 
class Piece
{
private:
	int x, y;
 
protected:
	virtual bool chkmv(int dx, int dy) const = 0;
 
public:
	Piece(int tx, int ty) : x(tx), y(ty)
	{}
 
	bool move(int dx, int dy)
	{
		if(!chkmv(dx, dy)) return false;
 
		x+=dx;
		y+=dy;
		return true;
	}
};
 
 
class Rook : virtual public Piece
{
protected:
	virtual bool chkmv(int dx, int dy) const
	{
		return !(dx && dy);
	}
 
public: // code dup :-(
	Rook(int x, int y) : Piece(x, y)
	{}
};
 
 
class Bishop : virtual public Piece
{
protected:
	virtual bool chkmv(int dx, int dy) const
	{
		return dx==dy || (dx+dy)==0;
	}
 
public: // code dup :-(
	Bishop(int x, int y) : Piece(x, y)
	{}
};
 
 
class Queen : public Rook, public Bishop
{
protected:
	virtual bool chkmv(int dx, int dy) const
	{
		return Rook::chkmv(dx, dy) || Bishop::chkmv(dx, dy);
	}
 
public: // code dup :-(
	Queen(int x, int y) 
		: Piece(x, y), Rook(x, y), Bishop(x, y)  // MAPA3M :-E
	{}
};
 
 
int main()
{
	Queen q(0,4);
	bool t1 = q.move(1,1);
	bool t2 = q.move(0,4);
	bool t3 = q.move(2,3);
	std::cout<<t1<<" "<<t2<<" "<<t3<<"\n";
 
	return 0;
}
 

Что мы тут имеем с гуся?
Ну, про дублирование кода в конструкторах я уже высказывался. Остается еще обратить внимание на совершенно феерическую фразу: «Piece(x, y), Rook(x, y), Bishop(x, y)». Два вызова из трех идут в никуда. И тем не менее без них оно не скомпилируется. В прошлом письме я уже про эту проблему с конструкторами виртуальных базовых классов говорил... Так что не будем о грустном. Посмотрим, лучше, как надо писать языки программирования это будет на perl:

Perl
use strict;
package Piece;
 
sub new
{
	my ($class, $tx, $ty) = @_;
	my $this = { x => $tx, y => $ty };
 
	# constructor inheritage
	bless($this, $class);
	return $this;
}
 
sub move
{
	my ($this, $dx, $dy) = @_;
 
	# virtual static function call
	return 0 unless ref($this)->chkmv($dx, $dy);
 
	$this->{x} += $dx;
	$this->{y} += $dy;
	return 1;
}
 
 
 
1;
package Rook;
our @ISA = qw(Piece);
 
sub chkmv
{
	return !($_[1] && $_[2]);
}
 
 
 
1;
package Bishop;
our @ISA = qw(Piece);
 
sub chkmv
{
	return $_[1] == $_[2] || ($_[1] + $_[2]) == 0;
}
 
 
 
1;
package Queen;
our @ISA = qw(Rook Bishop);
 
sub chkmv
{
	return Rook::chkmv(@_) || Bishop::chkmv(@_);
}
 
 
1;
package main;
 
my $q = new Queen(0,4);
my $t1 = $q->move(1,1);
my $t2 = $q->move(0,4);
my $t3 = $q->move(2,3);
print "$t1 $t2 $t3\n";
 

Итак, что у нас тут. Во первых, конструктор Piece::new. Он, как ни трудно видеть, наследуется. Это во-первых. Во-вторых, поведение этого наследуемого конструктора полностью соответствует тому, что мы имеем при виртуальном наследовании в C++: поля базового объекта создаются в одном экземпляре. Наконец, в-третьих — мы полностью контролируем процесс создания класса, так что, если нам такое поведение не понравится, мы можем с легкостью переопределить конструктор и изменить его (единственное, при множественном наследовании тут нужно быть достаточно внимательным и не забывать, что, по умолчанию, если конструктора нет, будет вызван конструктор только для первого из списка базовых классов).

Еще стоит обратить внимание на конструкцию ref($this)->chkmv. Здесь ф-ция вызывается не по имени объекта, а по имени класса. Т.е. ее с полным правом можно считать "статичексой виртуальной" — тоже фича, ни в C++, ни в D не поддерживаемая. (Другой разговор, что в данном примере нам абсолютно безразлично, как вызывать ф-цию — по классу или по объекту, и простой вызов $this->chkmv прокатил бы точно также... Но это уже детали. :))


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

Но это значит, что сначала придется отрефакторить исходный пример. Избавившись от "ромбика". Из-за которого весь сыр-бор был:

C++ (Qt)
#include <iostream>
 
class Piece
{
private:
	int x, y;
 
protected:
	virtual bool chkmv(int dx, int dy) const = 0;
 
public:
	Piece(int tx, int ty) : x(tx), y(ty)
	{}
 
	bool move(int dx, int dy)
	{
		if(!chkmv(dx, dy)) return false;
 
		x+=dx;
		y+=dy;
		return true;
	}
};
 
 
 
template<class PieceStr> class PieceImpl : public Piece, protected PieceStr
{
protected:
	// "using PieceStr::chkmv" don't work :-(
	bool chkmv(int dx, int dy) const
	{
		return PieceStr::chkmv(dx, dy);
	}
 
public: // code dup :-(
	PieceImpl(int x, int y) : Piece(x, y)
	{}
};
 
 
 
class RookStr
{
protected:
	static bool chkmv(int dx, int dy)
	{
		return !(dx && dy);
	}
};
 
class BishopStr
{
protected:
	static bool chkmv(int dx, int dy)
	{
		return dx==dy || (dx+dy)==0;
	}
};
 
class QueenStr : public RookStr, public BishopStr
{
protected:
	static bool chkmv(int dx, int dy)
	{
		return RookStr::chkmv(dx, dy) || BishopStr::chkmv(dx, dy);
	}
};
 
 
typedef PieceImpl  <RookStr>	Rook;
typedef PieceImpl<BishopStr>	Bishop;
typedef PieceImpl <QueenStr>	Queen;
 
 
int main()
{
	Queen q(0,4);
	bool t1 = q.move(1,1);
	bool t2 = q.move(0,4);
	bool t3 = q.move(2,3);
	std::cout<<t1<<" "<<t2<<" "<<t3<<"\n";
 
	return 0;
}
 

Мы избавились от "ромбика", выделив операцию в отдельный класс стратегии, а основной класс сделав шаблонным. Тем не менее, если мы хотим сохранить нормальный полиморфизм, все наши объекты по-прежнему должны иметь общую базу. И здесь мы видим еще один недостаток C++: для разрешения неоднозначности нам недостаточно написать в производном классе using PieceStr::chkmv: компилятор не воспримет PieceStr::chkmv как конкретизацию абстрактной Piece::chkmv. Мы должны явно ее переопределить. Но зато теперь мы, например, можем определить PieceStr::chkmv как static. Или вообще ее переименовать. Очень полезно, да...  :-\

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

Но, так или иначе, теперь мы можем свободно... почти... переписать этот код на D:

D
import std.stdio;
 
class Piece
{
private:
	int x, y;
 
protected:
	abstract bool chkmv(int dx, int dy);
 
public:
	this(int tx, int ty)
	{
		x=tx;
		y=ty;
	}
 
	bool move(int dx, int dy)
	{
		if(!chkmv(dx, dy)) return false;
 
		x+=dx;
		y+=dy;
		return true;
	}
}
 
 
class PieceImpl(alias PieceStr) : Piece
{
protected:
	mixin PieceStr; // ok
 
public: // code dup :-(
	this(int x, int y)
	{
		super(x,y);
	}
}
 
 
 
template RookStr()
{
	bool chkmv(int dx, int dy)
	{
		return !(dx && dy);
	}
}
 
template BishopStr()
{
	bool chkmv(int dx, int dy)
	{
		return dx==dy || (dx+dy)==0;
	}
}
 
template QueenStr()
{
	bool chkmv(int dx, int dy)
	{
		mixin RookStr Rk;
		mixin BishopStr Bs;
 
		return Rk.chkmv(dx, dy) || Bs.chkmv(dx, dy);
	}
}
 
 
alias PieceImpl!(RookStr)   Rook;
alias PieceImpl!(BishopStr) Bishop;
alias PieceImpl!(QueenStr)  Queen;
 
 
 
int main()
{
	Queen q = new Queen(0,4);
	bool t1 = q.move(1,1);
	bool t2 = q.move(0,4);
	bool t3 = q.move(2,3);
	writefln("%d %d %d", t1, t2, t3);
 
	return 0;
}
 

Классы стратей стали миксинами. Благодаря этому, мы избавились от необходимости переопределять chkmv в производном классе. Но тут же вылезла та проблема, о которой я говорил в первом письме. Множественное использование миксинов приводит к неоднозначности. Иными словами, код

D
template QueenStr()
{
	mixin RookStr Rk;
	mixin BishopStr Bs;
 
	bool chkmv(int dx, int dy)
	{
		return Rk.chkmv(dx, dy) || Bs.chkmv(dx, dy);
	}
}

компилироваться не будет. Чтобы обойти эту проблему, мне пришлось включить "наследуемые" миксины внутрь функции...

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


И еще одна проблема в том, что исходный вариант — с "ромбиком" который — на D перевести так и не удалось. Здесь можно возразить, что вариант со стратегиями гораздо лучше. Да, обычно это так. "Ромбик" не масштабируется. Но, с другой стороны, и не плодит лишних сущностей, в отличии от. И я вполне могу представить себе ситуацию, где все это масштабирование и гибкость, присущее стратегиям, нафиг не нужно. А вот про принцип KISS везде полезно помнить :)

И того, получаем, что в данном примере D снова на уровень C++ не тянет. Впрочем, сам C++ тоже решает исходную задачу не лучшим образом, требуя дублировать много кода.
Мораль: ждем, когда выйдет стабильная версия perl6 и сравниваем уже с ним. ;)
А пока ее нет, вывод один — «оба они хуже». :)