SiemarglПока я завязал с подробностями в D, пока не получу и не почитаю манифест Александреску (TDPL), как они это задумывали.Ура, приехала книжка. Будет чем заняться в отпуске =)

В общем итоги.
Сначала о книге Александреску:
- хорошо написана с грамотными примерами, которые отвечают на еще незаданные вопросы
- чувствуется рука практика - поясняется почему и для каких случаев применения задуман тот или иной синтаксис языка, и какие накладные расходы это тянет
- введение в метапрограммирование очень мягкое, но кроме базовых понятий и примеров, детально вглубь не уходит (мне жаль)
- похоже, что автор изучил _все_ языки и концепции и сравнений с ними много и библиография очень широкая

Что касается языка. Нет никаких сомнений, что D как язык уже сейчас мощнее C++0x

Ключевые отличия:
-продуманный аспект безопасного использования. То что скомпилировалось, с более высокой вероятностью будет вылетать редко. К этой стороне относятся:
-- встроенные массивы (в т.ч.ассоциативные) с проверками границ (отключаемыми в релизе), концепции работы с объектами (только безопасные ссылки в динамической памяти) - это делает работу с указателями в большинстве случаев ненужной;
-- design by contract, инварианты для объектов, встроенные юниттесты и тесты покрытия;
-- более жесткая модульность программ (почти дельфийские юниты), неизменяемые типы данных immutable (с наследованием связанных членов), неделимость данных между потоками по умолчанию
-- исключения могут порождать цепочки для анализа первопричины
-- концепция scope(exit/success/failure), упрощающая RAII в реализации - без многоуровневых try/catch
-- встроенные безопасные Variadic Parameters для функций

-продвинутость/гибкость самого языка
-- параметризованные типы, классы и функции с более широким выбором (возможно условных!) специализаций, Variadic Template Parameters
-- CTFE с typeof и условными шаблонами дают сумасшедшую гибкость
-- tuples, делегаты, лямбды, замыкания (closures), в т.ч.для вложенных классов, а не только функций
-- alias, которые подобны макросам, но могут применяться везде вместо любого литерала
-- встроенные через перегрузку операторов таблицы диспетчеризации

-подход к производительности
-- pure, математически "чистые", т.е.без побочных эффектов функции. Проверяется на этапе компиляции, может дать в будущем продвинутые оптимизациии
-- потоки встроены в язык и приняты меры для устранения race conditions и выбивания кэша. Данные по умолчанию не делятся между потоками, либо являются заведомо immutable. Базовая концепция - обмен между потоками через очереди сообщений (построенные на механизме exception'ов), хотя есть и обычные synchronized классы (но со своей фичей - умением делит мютекс с подэлементами и мульти-мьютексами)
-- встроенная поддержка атомарных операций, cas (Compare-and-swap) и ассемблера дает возможность писать lock-free многопоточные программы (хотя нетривиально)

Ну и целая гора синтаксического сахара - не перечислишь...

Anatoly MoskovskyВот еще семинар по D с Александреску, который недавно в Гугле был.
http://www.youtube.com/watch?v=RlVpPstLPEc

алчность,

Вопрос неточный. Тела функции должны отличаться при специализациях или как?
Нужно видеть полный аналог на С++.

ЗЫ. Подозреваю, что в любом случае обойдется заменой угловых скобок на круглые )

Общий шаблон. Подойдет и для (int,int) и для разных, но специализации имеют преимущество

Специализации на вкус и цвет (кстати пример - возврат функции вычисляется = deduce)

Если быть _абсолютно_ точным, то так:
D:\dmd2\z>reverse.exe
x = 1.5, y = 1

Никак не пойму, чего надобно....Такой вариант
int value = 5, double value = 1.1
int value = 4, double value = 2.4
А еще можно сделать variadic func(...){ foreach(param) ...}

k0rvinSiemarglНикак не пойму, чего надобно

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

на самом деле получаем 6 функций foo

с одним(одинаковым) телом.
Тогда пример за вчера 18:30 верный.

Anatoly MoskovskyСправдливости ради, с оглядкой на тему, надо отметить что в C++0x все эти фичи есть безо всяких бустов :)
Есть в стандарте, но пока не в реализациях (хотя может уже в передовых компиляторах типа Metrowerks или Comeau). Ждемс

алчность,

Ну не на с++, а на чистом с =)

Проверки на этапе компиляции часто стоят того. Например, мой пример с (bool, double) точно не скомпилится, а вот с макросом - может )

ЗЫ. Переводил вчера шаблонные тесты Степанова (там врапперы и итераторы) с шаблонов С++ на D. Оказалось не очень тривиально и результат по скорости хуже =(

Нашел такой простенький визуальный дизайнер под DWT (порт SWT) и DFL (D Forms Library).

Возможностей минимум, зато простой читаемый код библиотеки DFL под Win32.

Результирующая программа заняла 1Мб на диске (статическая линковка) и 2! Мегабайта в памяти. Чего я давно не видел для программ с GUI.

Сделать что ли клона Дельфи )))

ЗЫ. Очень порадовало, потому что в обед собрал unittest для dlib (ищу замену бусту). Так вот - получилось .exe 10 Мб, не считая g++*.dll (после стрипа, MinGW 4.5)

"Обратный ход маятника"

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

1. Поскольку язык - не Си, есть проблема импорта системных хидеров ОС. Она не такая страшная, как в Pascal и VB, т.к. есть прямые аналоги типов, но все же ручная работа требуется.
Например, в версии 1.0 нет поставляемой библиотеки импорта Win32 API, и потому сообщество создало много своих версий - я встретил 4 разных реализации, и все неполные.
/2Off полные реализации Win32 API есть и не во всех C++ компиляторах. Например, нужные мне CreateFileTransacted есть только в MSVC и WatcomC, а в MinGW, DMC - нет.

2. Переход на UTF-8 в строках и исходниках. char[] str = "русский текст" - это не 14 байт, а больше. И хотя способ посимвольно итерироваться встроен (итератор UTF-32), но печать в консоли - автоматически не декодируется (и chcp 65001 не спасает). А требуемая ф-ция Win32 CharToOEM не включена как оказалось, в стандартную либу 2.0. "Простой вопрос, а ставит Вас в тупик" (с)

-Компилятор не понимает исходники в 1251, только любой Юникод.


3. Неразвита инфраструктура и вторичные неудобства.
-Местами компилятор дает невнятную диагностику ошибок - ссылаясь не на первопричину ошибки, а на место возникновения, и наоборот.

- Поскольку компилятор однопроходный, пока часть критичных ошибок не устранишь (импорт модулей, описание и инстанциация шаблонов) - все ошибки не покажет. Зато быстрый.

/2off В C++ такое веселье в основном только в шаблонах, и то всем силами с ним борются.
-Нет полноценного отладчика и профайлера скорости выполнения.

-Нет фреймворков - GUI, Database, GameDev, см.также ниже. Особенно касается версии 2.0

4. Полным ходом неразбериха "оперсорсного типа". Что где валяется и когда это все кончится! (с)

-в разных библиотеках применены разные утилиты сборки. Я насчитал make (Borland-style), make (GNU-style), bud/build, dsss, rake, bob

- библиотеки написаны в основном под D1+Tango и нихрена не идут без большого! напильника под D2+Phobos stdlib и даже хуже. Пример:
Плановая стандартная GUI = порт GUI Java SWT 3.4 +JavaFX называется DWT. 16,5 Mb исходников. Написана под dmd1.33+tango0.99.7.
При этом наотрез отказывается собираться и если взять DMD1.63 (текущая) и если взять Tango 0.99.9 в любой их комбинации. Теоретически, есть версия DWT под текущую версию D1+Tango, но ее надо качать из девелоперской ветки (это еще проверю). Под D2.0 - есть только совсем сырая - еще даже не альфа DWT2.

5. Документация. Для компилятора, стандартных тулзов и phobos - хорошая. Другие либы относительно опенсорса - неплохой уровень, но не более.

Короче, нужно быть достаточно упертым или быть корпорацией, чтобы подготовить под себя полный тулсет. В текущем состоянии он далеко отстает от C++/Java/C# и местами от Delphi.

SiemarglТеоретически, есть версия DWT под текущую версию D1+Tango, но ее надо качать из девелоперской ветки (это еще проверю).Работает на текущих D1.063+Tango0.99.9