C++ vs D

[ритт]

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

[ритт]

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

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

[pastor]

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

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

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

[Eldar]

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

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

[Eldar]

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

[vaprele07]

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

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

Пример сказанному:

Код:

<group> x=0 y=95
image x=20 y=15 path=themes/default/cpu.svgz

text x=60 y=0 sensor=program program="cpuinfo=$(grep 'model name' /proc/cpuinfo | sed -e 's/.*: //' -e 's/(tm)//'); if test ${#cpuinfo} -lt 35; then echo $cpuinfo; else echo -n $cpuinfo | cut -c -31; echo ' ...'; fi"
graph x=150 y=16 w=70 h=30 sensor=cpu cpu=0 format="%user"   color=96,148,207 interval=1500
graph x=150 y=16 w=70 h=30 sensor=cpu cpu=0 format="%system" color=226,7,0    interval=1500 
graph x=150 y=16 w=70 h=30 sensor=cpu cpu=0 format="%load"   color=255,255,153    interval=1500 

text x=60 y=12 value="User" color=96,148,207
text x=60 y=24 value="System" color=226,7,0
text x=60 y=36 value="Total usage" color=255,255,153

text x=260 y=12 sensor=cpu cpu=0 format="%user %" align=right interval=1500 color=96,148,207
text x=260 y=24 sensor=cpu cpu=0 format="%system %" align=right  interval=1500 color=226,7,0
text x=260 y=36 sensor=cpu  cpu=0 format="%load %" align=right interval=1500 color=255,255,153

text x=60 y=48 value="CPU temperature:"
text x=260 y=48 sensor=program program="sensors | grep Core0| cut -f2 -d+ | cut -c -7" interval=1500 color=220,220,220 align=right

</group>

Подобное на языке "X"

Код:

image = new Image(10, 15, "themes/default/cpu.svgz");

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

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

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

[KADABRA]

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

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

[Detonator]

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

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

[Tonal]

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

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

Я бы не сказал что вызовы st.processStruct() по сравнению с processStruct(st) дают серьезный выйгрыш в производительности. Также как и конвертация хидеров(которую можно проводить автоматически )

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

Вы так и не разъяснили какой выйгрыш в производительности дает st.processStruct() по сравнению с processStruct(st) . Честно - не пойму.

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

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

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

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

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

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

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

[vaprele07]

запись вида:

Код:

struct Node
{
  map<type1, Node> child;
};
map<type1, Node> root;

[Detonator]

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

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

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

[pastor]

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

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

[pastor]

2 Detonator:

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

[BRE]

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

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

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

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

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

[Detonator]

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

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

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