Delphi 2009

[metaclass]

описание новых фич

Судя по всему, Embarcadero всерьез взялись за дельфи, судя по новой версии. Фичи вроде generics и юникода по умолчанию в win32 - это очень хорошо, счас осталось производителям компонент переползти на это дело и можно будет вслед за ними переходить.
Им бы туда еще метапрограммирование добавить, вообще бы killer feature была бы.

PS: Атомная смерть, они туда и closure добавили. Прозреваю окопавшихся функциональщиков, которым в борланде менеджеры не давали развернуться на всю катушку :)

Comments

[aamonster.livejournal.com]

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

Жаль, что шансов у дельфей все равно немного.

[guamoka.livejournal.com]

Жаль, что шансов у дельфей все равно немного.


Ну, лично мне- ни капельки. Потому что это Pascal/Delphi как язык плетется в сторону к C++ и никак не может дойти, а не наоборот (что в общем-то подтверждает правоту Страуструпа в видении языка).


Ну, дельфовский паскаль по жизни был не так далек от C++


Бось, Страуструп/Александреску/Мейерс и др. с вами бы не согласились. Очень не согласились бы:)

[metaclass.livejournal.com]

Кстати, я что-то запамятовал - в C++ виртуальные конструкторы и ссылки на типы классов есть?
А то в дельфи я их постоянно использую, а в С# очень дико бесит их отсутствие.

[tonal.myopenid.com (from livejournal.com)]

>в C++ виртуальные конструкторы и ссылки на типы классов есть?
В стандартном С++ нету. Если нужно - просто делаются руками, например как в COM.
В диалекте от багланда есть для классов унаследованных от TObject.

Кстати, несмотря на то, что на Delphi использовал эти возможности переходя на С++ прекрасно обходился без них. А вот RAII в Delphi типало постоянно.
(с делфи плотно общался с 4ки по 7ку включительно).

[guamoka.livejournal.com]

1. Ноуп. За всю историю использования С++ помню только один случай (о-очень давний, о-очень смутно), когда мне стукнуло в голову, а почему, собственно, нет виртуального конструктора? Перекрестился. Помогло.
2. Если ты имеешь в виду RTTI, то да. Базовая реализация простейшая. Расширяема, насколько я уяснил. Когда я активно программил на C++, то этим пользоваться как-то не доводилось. Имхо, зависит от приложения. Вероятнее всего, твоя задача, в которой используется RTTI, может быть решена на С++ шаблонами и несколько иным способом. Если, конечно, это не дикий динамический инструментейшен или вызовы функций через нечто наподобие рефлекшен. Тогда, вероятно, сторонние библиотеки и реализации (e.g. IDispatchImpl, или как там эта хрень называлась...)

[hollisglazier.livejournal.com]

В то время я был на Lucent'e, а Ubuntu (как и Mandriva) отказался работать с soft win модемом.

[lonnyjardain.livejournal.com]

В то время я был на Lucent'e, а Ubuntu (как и Mandriva) отказался работать с soft win модемом.

[aamonster.livejournal.com]

Услышав слово "Александреску", бешено заскрежетал зубами и очередной раз подумал об уходе на более адекватные языки.

Нет, ну неужели вы и вправду считаете, что извращения в стиле Александреску (ТЯЖЕЛОЕ "метапрограммирование" на шаблонах) - это нормально? И в реальной жизни годится на то, чтобы быть чем-то большим, чем "proof of concept"? Идите к функциональщикам, они вам объяснят, как это делается более адекватно.

[aamonster.livejournal.com]

Иначе говоря, Александреску - математик, доказывающий теоремы о языке C++. Не программист ни разу.

[guamoka.livejournal.com]

У меня порой создается впечатление, что народ как правило не совсем понимает позиционирование C++, хотя, если мне не изменяет память, Страуструп озвучивал его достаточно четко и по многу раз.

Да, возможно, Smalltalk- это более ОО язык, чем С++. Да, возможно, Lisp- это более естественный для FP язык, чем С++. Да, возможно, С позволяет писать более компакный и быстрый код, чем С++. Но что объединяет сильные стороны всех этих языков и парадигм программирования? Именно. Тот самый С++. Уже не говоря про тему топика 'Delphi/Pascal и новые фитчи', которая как-то в приступе ненависти к С++, темплейтам и ФП сразу же позабылась:)


Идите к функциональщикам, они вам объяснят, как это делается более адекватно.


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

[aamonster.livejournal.com]

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

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

[zamotivator.livejournal.com]

Дорогой, у нас проект - СУБД, и ПОШЛИ НАХУЙ НЕНАВИСНИКИ Александреску, ибо метапрограммирование в плюсах поднимает, причём ОЩУТИМО производительность.

Можно сказать "пишите DSL и генерируйте специализации" - встречный вопрос, нахуя козе боян если уже есть плюсовые шаблоны?

Прозрева. вероятность того, что афтар просто ниасилил

[metaclass.livejournal.com]

Эээ, так вы ж вроде и собираетесь в итоге использовать DSL на основе LLVM? :)

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

[zamotivator.livejournal.com]

llvm только будет, и ему пока что нужна альтернатива.
Плюс мы не откажемся до конца от статического метапрограммирования.
Грубо говоря, отдельные кубики что до сих пор рулятся на виртуальных вызовах будут связываться llvm'ом, но внутри себя кубики связываются статически.
Иначе говоря - всё что не слишком долго (с точки зрения компиляции), дорого (с точки зрения объёма бинаря), и стабильно (с точки зрения рабочести компилятора) будет и далее "генерироваться" обобщенным кодом.

[aamonster.livejournal.com]

Если бы "ниасилил" - было бы смутное ощущение, что это круто.
Беда именно в том, что прочитал, понял и изумился - нахуя.

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

[zamotivator.livejournal.com]

Я немало холиварил на эту тему, и поднимать старый труп снова - не хочу.
Построить производительное СУБД требует либо написания кода на языке низкого уровня - С, С++, asm, llvm IR; либо генерации этого низкоуровневого кода из DSL/высокоуровневого языка.

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

Писать на LLVM IR - убьёшься тапком + неявно platform-dependent (чтобы не было platform-dependent - генерить LLVM IR из C/C++ нужно).

Построение DSL, который выполнит такую генерацию - более трудоёмко, чем написать такую систему на С++ целиком.
А метапрограммирование на плюсах является по сути интеграрованным в С++ DSL'ем, что занимается генерацией кода.

Если есть ещё вопросы - задавайте.

[aamonster.livejournal.com]

Да нет, спасибо. По сути ведь ответ сводится к "предметная область потребовала" - звучит понятно и разумно.

[zamotivator.livejournal.com]

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

[aamonster.livejournal.com]

Но этих областей не так много и обойтись все же можно - т.е. язык без шаблонов имеет право на жизнь.

А использование метапрограммирования на шаблонах там, где не надо - создает много проблем. Куда больше, чем использование без необходимости виртуальных функций или RTTI. Почему и возникает желание отобрать эту возможность у 99% программистов (90% ее не используют вообще, еще 9 - используют не по делу).

[zamotivator.livejournal.com]

Это естественно.
Таки извраты нужно исключительно из-за производительности.

[aamonster.livejournal.com]

Угу. Самому раз в жизни понадобилось (ну, не считая вещей типа контейнеров и смартпойнтеров, и, естественно, использования по назначению - для создания однотипных классов/функций) - заменить вызов виртуальной функции при реализации Fast Marching (это из обработки изображений - по сути, последовательный обход всех пикселов определенным образом). И то - если бы в языке были Closures (и они нормально оптимизировались), это бы, кажется, не понадобилось, а код был бы заметно проще.

Хорошо, что языки потихоньку развиваются. В тот же C++ должны прийти вещи типа closures. В C# и, кажется, яве и D они уже есть. Вообще C# мне нравится больше C++ (хотя бы синтаксис объявления типов переменных) - но осознаю, что неправильное использование кучи может создать жуткие тормоза (так-то по моим тестам managed код уже вышел на уровень производительности native). К сожалению, перейти не так просто - проекты уже на c++, да и для реального использования нового языка надо изучить не сам язык (дел на несколько дней), а библиотеки (причем так, чтобы не задумываться, какой класс/вызов использовать - а это не просто изучение, а тренировка).