DMD 2.015 & DMD 1.031

> Долой класс ориентированное ООП!

оно тебе жить мешает? :)

А какой компилятор лучше - dmd или gdc? Интересует прежде всего поддержка стандартов.

Каких стандартов?

хватит оффтопить. тут говноплюсы обсуждаются.

>хватит оффтопить. тут говноплюсы обсуждаютс

Сорри, но можно еще раз за офтопить. Чем отличается диспетчер процессов от планировщика процессов? Загуглить сходу не получилось, так что в ртфмстве пжалуста не обвинять.

Такое впечатление, что D половине лора в щи нассал.
Отрадно смотреть, как отплёвываетесь.

>> Ну и вопрос, на который не ответил Анонимус I - представь себе глубоко вложенные вызовы функций, и тебе нужно поменять тип где-то в глубине.

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

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

>> Ну и вообще такие вещи решаются грамотной организацией процесса разработки, работой с заказчиком и прочими нетехническими мерами.

> Угу угу. Предварительное проектирование, грамотная организация процесса разработки, работа с заказчиком, невиноватым дадим пирожок с плки, виноватых накажем итд итд.

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

какое мне дело, я буду молчать? (с) лучше б не умничал, а привел доводы - чем D лучше/хуже

>Каких стандартов?

То, что описано в http://www.digitalmars.com/d/2.0/lex.html.

> auto i = arr.iterator;

> Нафига мне здесь писать тип i?

Угу, особенно когда итератор надо взять от чего-нибудь типа std::tr1::unordered_map < std::vector < std::pair < ClassA , std::vector < std::string > > >, ClassB, Hash1 <...> > ...

Конечно можно ввести typedef, но бывает лень.

Быстрей бы фича с auto в С++ появилась.

> препроцессоры нужны, но только для условной компиляции, имхо. Встречал быдл, которые на макросах писали все, даже классы. Таких надо мочить без разбору.

Ты не работал с компилятором cfront. Там поддержка темплейтов была настолько убогая, что только и оставалось на макросах классы писать.

за дерево из 15 наследований архитекторов (или быдлокодеров ? ) надо за яйца подвешивать

А мне понравился язык. Как раз недавно из любопытства ковырял. И tango - достаточно приятная библиотека к нему.

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

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

Perl6 и Javascript рулят?
BTW, какие ещё есть языки с прототипами?

>Мне тоже нравятся "чистые" функции, но я всё же не вижу принципиальной разницы между ними и методами.

Если меняешь сигнатуру функции - ломаешь всех кто инклудил один .h файл. Меняешь сигнатуру метода базового класса - ломаешь все нижестоящие .h файлы с производными классами, сами производные классы и всех кто их использовал.

BTW не вижу проблем пометить функцию как deprecated и медленно ее вычистить.

> и вызвать метод, который неоднозначно определяется в разных предках?

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

> Если меняешь сигнатуру функции - ломаешь всех кто инклудил один .h файл. Меняешь сигнатуру метода базового класса - ломаешь все нижестоящие .h файлы с производными классами, сами производные классы и всех кто их использовал.

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

>>Мне тоже нравятся "чистые" функции, но я всё же не вижу принципиальной разницы между ними и методами.

>Если меняешь сигнатуру функции - ломаешь всех кто инклудил один .h файл. Меняешь сигнатуру метода базового класса - ломаешь все нижестоящие .h файлы с производными классами, сами производные классы и всех кто их использовал.

Я говорил не об этом... но в любом случае, объясни мне принципиальную разницу между изменением сигнатуры метода и свободной функции. То, что ты сказал, ничего не объясняет. Разницы между "инклудил один .h файл" и между "все нижестоящие h файлы с производными классами, сами производные классы и всех кто их использовал" я просто не вижу.

>> Если меняешь сигнатуру функции - ломаешь всех кто инклудил один .h файл. Меняешь сигнатуру метода базового класса - ломаешь все нижестоящие .h файлы с производными классами, сами производные классы и всех кто их использовал.

>[...skipped...]

Поучи жену щи варить.

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

>Разницы между "инклудил один .h файл" и между "все нижестоящие h файлы с производными классами, сами производные классы и всех кто их использовал" я просто не вижу.

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

> Слишком сферическая аналогия в вакууме - давно видать на плюсах не кодил.

Давай конкретней. Здесь речь не идет о деталях, которые старый Си++-кодер может забыть.

> Вплоть до предоставления непосредственно кода клиенту кода в .h файле.

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

>берешь нормальный IDE, правой кнопочкой на методе и там выбираешь рефакторинг

Неужели под Линукс есть нормальная IDE для С++? Эклипс+CDT меня совсем не впечатлил в этом отношении.

>а какие есть серьёзные проекты на Эйфеле? а то вдруг интересно стало. Желательно с DBC и юниттестами понатыканными.

http://www.eiffel.com/executives/customer_testimonials1.html http://www.eiffel.com/general/customers.html

>за код в .h файле руки надо отрывать( это не в вашу сторону, я уверен вы так не пишите ), можно плз пример, почему в плюсах это бывает необходимо( ни разу не было такой необходимости )

Для шаблонов конечно.

к сожалению лучше Eclipse нет :(, у меня проект создан под Visual, xCode 3.1, Eclipse, потому в случае такой надобности я скорее всего сделаю это в оффтопике или xCode

> к сожалению лучше Eclipse нет :(

Visual SlickEdit.

Впрочем, CDT5 неплох (правда, рефакторингом я не пользуюсь).

> Будет глядеть, будем. Вот выйдет версия 2, вот подтянется gdc, и поглядим :)

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

> ни разу не было такой необходимости

Значит ты писал не на плюсах, а на подмножестве плюсов.

Как реализовать шаблоны вне .h файлов и inline'ы может расскажешь?

> Наследование строго не рекомендуется использовать везде где это возможно.

Честно говоря, со временем всё больше убеждаюсь, что ООП вообще лучше не использовать, если это возможно

> - встроенная поддержка списков - встроенная поддержка регулярных выражений - лямбда-выражения и функции высших порядков - возможность расширения классов и объектов (пусть даже не динамическая, как в руби или питоне, а как в C# 3.0) - систему метапрограммирования, например как в Nemerle - компактность языка

Встроенная поддержка регулярных выражений была где-то в районе версии 0.060. Потом выбросили за ненадбностью. Остальное в той или иной степени есть или планируется.

> Впрочем, CDT5 неплох

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

> А какой компилятор лучше - dmd или gdc? Интересует прежде всего поддержка стандартов.

dmd - reference compiler, только он не умеет динамические библиотеки делать.

> Значит ты писал не на плюсах, а на подмножестве плюсов

я не ставил себе за цель использовать все :)

> Как реализовать шаблоны вне .h файлов

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

> Категория OpenSource, а компилятор проприетарный.

Распознавалка свободная. А кодогенераторов свободных - как минимум gcc(gdc) и llvm(llvmdc).

(Когда уже народ осилит поиск?)

>Как реализовать шаблоны вне .h файлов может расскажешь?

Это реально. Пишешь тело шаблона в .cpp файле, потом в этот же файл добавляешь явные инстанциации шаблона по мере их появления. Круто, да?

Сегодня вышла книга "Программирование на D" от Вассермана и Спира: http://tinyurl.com/66j229 :D

я еще один не осиливший :) есть ли где-то вменяемые и достоверные тесты по сравнению производительности скомпилированного кода С\С++\D ?

> есть ли где-то вменяемые и достоверные тесты по сравнению производительности скомпилированного кода С\С++\D ?

Вменяемее и достовернее http://shootout.alioth.debian.org не знаю.

(Означает ли этот вопрос, что Вы близки к скачиванию компилятора?)

На данный момент по их результатам производительность gdc совпадает с gcc. 0_o Обычно он _чуть_ медленнее код генерит.

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

да нет же - судя по тестам раза в полтора в среднем код более медленный

Онотоль програмит на D? ;)

Если в планах есть писать проги, курить это:

http://www.dsource.org/projects/tango
http://www.dsource.org/projects/dsss
и компилятор первой ветки.

Если играться, то http://rosettacode.org/wiki/Category:D и компилятор второй ветки.

пока на поиграться - спасибо за ссылки

С памятью пробемы из-за GC, хотя у Джавы с памятью проблемы ровно в 10 раз больше. По чистому процессорному времени DMD уступает gcc на 10-30%, gdc - на 0%. Проверь числа в правом столбце на странице с результатами.

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

Лучше даже не просто компилятор первой ветки, а именно 1.029. Это последняя версия, у которой не обнаружили новых багов. :(