GDB 7.2

> Видим просто образцовый случай Blub Paradox'а.

Во-первых, ваш ответ не имеет отношения к моему вопросу.

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

В третьих, Лисп имеет очень ограниченный синтаксис и приходится ориентироваться на семантику. Для большинства программистов это намного труднее, чем ориентироваться на синтаксис. Именно по этой причине (в первую очередь) Си-плюс-плюс считается сложнее, чем Си. И по этой же причине язык Лисп мало используется на практике по сравнению с Си, Java, Бейсиком.

>> решение сделать все функции виртуальными по умолчанию ничем не лучше «плюсового» решения

как в Яве же.

Да, это я и сам сразу понял.

Поведение виртуальных функций более очевидно для былокодера.

Неужели? Обоснуйте. Кто вам сказал, обнаружить ошибку из-за наличия невиртуальной функции, которую случайно забыли сделать виртуальной, проще для былокодера, чем ошибку из-за отсутствия виртуальной функции у потомка (при наличии у родителя), которую просто забыли написать.

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

Лично я их игнорирую потому, что их синтаксис уж больно аскетичен/экзотичен, а возможности все в принципе есть, но реально их надо реализовывать самому. То же ООП - явный пример. Плюс, я уже «испорчен» с-подобными языками. И, разумеется, «as fast as C» (и практически так же не прожорлив по памяти) роль играет. Плюс для меня удобнее, когда функциональные возможности вкладываются в имеративный каркас, а не наоборот.

Не написано на нём почти ничего в основном потому, что за ним сразу заявили D2 - несовместимый, но со множеством вкусных фич. Вот и ждём... А пока библотеки появляются потихоньку.

Что касается finally - в D есть дух плюсво в том смысле, что не заставляют что-то делать только одним способом. Хочешь - используй стековые классы и RAII. Хочешь используй дишные скопы. Хочешь - финалли. В принципе, на сайте есть статья, где описано, когда что луче применять.

С решением сделать все функции виртуальными тоже как раз всё ясно - автор счёл это деталью реализации (и не он первый, кстати - хоть java вспомнить). Где надо, компилятор соптимизирует вызов.

Добавьте pure-функции из D2 и всю возможную с их введением чистую функциональщину, где надо

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

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

Кстати, о птичк... в смысле о быдлокодерах. Если уже упрощать язык, то надо было в языке Ди некоторые проблемы языка Си решить. Тот же приоритет операторов в Си был принят исходя из совместимости с языком Би. И получилось не всегда оптимально. Например, в выражении (a&mask) == 0 легко забыть скобки. Кроме того && и || было бы проще писать в виде and и or. Это немного упростило бы внешний вид сложных выражений. Да и тихое падение через конструкцию switch-case для новичков лучше отменить.

>> Например, наличие ключевого слова finally ведёт к плохому стилю программирования,

без этой парадигмы невозможно представить например дотнет

> компилятор Си-плюс-плюс вполне может ругнуться, если невиртуальная функция «перекрыта»

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

Насколько я помню, в D у структур методы не виртуальные, кстати. Но основная суть - в том, что писание явное «virtual» ничего не даёт. D-компилятор имеет достаточно информации для принятия кучи оптимизирущих решений - собственно, это был один критериев разработки языка. И отлично оптимизирует выиртуальные функции. Ну а что касаетсяоверхеда на Vtbl - вы меня повеселили. Такая жесть разве что в суровом эмбеде может потребоваться.

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

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

>Например, в выражении (a&mask) == 0 легко забыть скобки.

побитовые операции? быдлокодерам?

Кроме того && и || было бы проще писать в виде and и or

возможно. думаю, их сделали символьными, чтобы не засорять язык идентификаторами, хотя я бы не стал использовать and или or для названий переменных

Да и тихое падение через конструкцию switch-case для новичков лучше отменить.

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

> Плюс для меня удобнее, когда функциональные возможности вкладываются в имеративный каркас, а не наоборот.

Мсье любитель ходить на костылях, сделанных из бетона. Понимаю.

>D-компилятор имеет достаточно информации для принятия кучи оптимизирущих решений - собственно, это был один критериев разработки языка.

не имеет, а должени иметь - в результате разработка компилятора еще сложнее, чем для плюсов

> кстати - хоть java вспомнить). Где надо, компилятор соптимизирует вызов.

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

Во-вторых, Уолтер Брайт мотивирует своё решение не производительностью, а борьбой со случайными ошибками. Я на это уже отвечал в сообщении выше anonymous (06.09.2010 14:06:55).

компилятор Си-плюс-плюс вполне может ругнуться, если невиртуальная функция «перекрыта»

Это его надо специально попросить, наверно.

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

> Где надо, компилятор соптимизирует вызов.

как показывает практика, если нужна реальная оптимизация, лучше придерживаться концепции «компилятор - дурак» :)

> как показывает практика, если нужна реальная оптимизация, лучше придерживаться концепции «компилятор - дурак» :)

Торвальдс, помню, громко ругался, когда компилятор с ним в этом не согласился.

> > Кроме того && и || было бы проще писать в виде and и or

возможно. думаю, их сделали символьными, чтобы не засорять язык идентификаторами

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

Да и тихое падение через конструкцию switch-case для новичков лучше отменить.

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

Ну, «назначить один блок нескольким вариантам» это отдельный вопрос. Причём тут єто? Может имелось ввиду частичное совпадение нескольких вариантов. Тогда это performance hack. Такие вещи нельзя делать красивыми (страшные вещи должны и выглядеть страшно). Но при сильном желании можно просто явное ключевое слово для этого добавить. Главное чтобы случайно (по недосмотру) тихих падений не было.

можно вообще свитчи упразднить, так как они убивают ООП и полиморфизм :)

>Может имелось ввиду частичное совпадение нескольких вариантов

полное тоже бывает

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

Вот что он пишет: Virtual functions are functions that are called indirectly through a function pointer table, called a vtbl[], rather than directly. All non-static non-private non-template member functions are virtual. This may sound inefficient, but since the D compiler knows all of the class hierarchy when generating code, all functions that are not overridden can be optimized to be non-virtual. In fact, since C++ programmers tend to «when in doubt, make it virtual», the D way of «make it virtual unless we can prove it can be made non-virtual» results, on average, in many more direct function calls. It also results in fewer bugs caused by not declaring a function virtual that gets overridden.

То есть основная причина - что решение о виртуальности лучше переложить на компилятор, а уже побочная - fewer bugs.

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

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

C-styly switch - это уже такая классика, что не знать её, мне кажется, уже невозможно. Зачем путать программистов? Хотя, в принципе, можно было бы добавить альтернативный switch-оператор с другим именем и логикой. Было бы вполне в стиле D, с его приоритетом возможностей.

Так далеко не все всем нужно ООП и тем более полиморфизм. А D как системный язык позиционируется, вообще-то, и как язык, который не ограничивает програмиста (с этим к яве и Go), а даёт возможности.

> Во-первых, ваш ответ не имеет отношения к моему вопросу.

Имеет.

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

Я и не обсуждал. Blub Paradox наблюдается в людях, а не языках.

Лисп это функциональный язык

Нет, не функциональный.

> не имеет, а должени иметь - в результате разработка компилятора еще сложнее, чем для плюсов

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

>Вы таки считаете, что разработка компилятора должна быть проще, чем программ, им компилируемых?

нет, я просто считаю, что глупо целиком полагаться на ум компилятора

> D compiler knows all of the class hierarchy when generating code

Как такое вообще возможно?

>Как такое вообще возможно?

ну если не хранить модули в динамических библиотеках (т.е. готовых бинарях), то что мешает на момент... ммм, «окончательной компиляции» конечной программы, скажем так, «знать» всю «class hierarchy»?

P.S. Внутренностей D не знаю

P.P.S. Понятно, что в этом случае все «готовые» модули должны храниться в виде некоего AST-а, как-то так... =)

> ну если не хранить модули в динамических библиотеках

И вообще в библиотеках.

ну да, «классические статические библиотеки» тоже не годятся

> добавлена поддержка для языка D;

Не может не радовать. Раньше с D (компилятор ldc) работало довольно таки криво.

GDB 6.8-debian. KDBG как фронтенд. Показать скрины?

> Вот только когда уже D2 выйдет, кто б знал...

Кому надо тот скачал нужную версию dmd и пользуется.

>> D compiler knows all of the class hierarchy when generating code

Как такое вообще возможно?

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

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

Сам ты сосешь, а Clang рулит.

Так ведь какой-то некромант не так давно снова взялся за GDC. Хотя LDC по-прежнему рулит.

> Для D второго уже есть компиляторы?

DMD, и, говорят, экспериментальная поддержка есть в ldc (хотя сам не видел).

какой еще LDC? DMD же

> Например, наличие ключевого слова finally ведёт к плохому стилю программирования

Каким образом?

решение сделать все функции виртуальными по умолчанию ничем не лучше «плюсового» решения

Что имеется ввиду под «плюсовым» решением?

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

в AOT нет загрузки левых классов в рантайме

> А в случае языка Ди ещё и отклоняются от основных идей языка Си-плюс-плюс в худшую сторону без оснований.

1. С каких пор D - диалект плюсов?
2. Почему D должен следовать основным идеям плюсов?

>Как такое вообще возможно?

может он IPO делает

Где в D костыли и тонны синтаксического хлама?

>интересно когда в него добавят поддержку stl

И Qt

> Препроцессор жалко конечно)

В 90% случаев препроцессор нужен для создания кроссплатформенного кода, в D для этого свои средства.

>Компилятор много проще. D специально проектировался с учетом простоты компиляции.

поверхностный анализ литературы показал, что перед этим компания Digital Mars производила компилятор C++, отличавшийся весьма посредственной оптимизацией. Значит, решили упростить задачу, подогнав язык под свои возможности :)

>В 90% случаев препроцессор нужен для создания кроссплатформенного кода

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