<iostream.h>

>> К чему болтовня, давай примеры сортировки на си и плюсах, проверим.

> http://theory.stanford.edu/~amitp/rants/c++-vs-c/

В appendix-е есть все сорцы.

>objective c в разы логичнее и изящнее

Согласен. В нем smalltalk-подобная система классов, слоты и сигналы - родная для него вещь. А в быдло-цпп приходиться писать такие костыли как препроцессоры Qt moc от Trolltech. Говно это, а не язык.

> на плюсах вообще трудно найти красивый большой проект(и а плане архетектуры и в плане кода)

Маленькая программа на C++, perl, java и т.п. выглядит прекрасно, в то время как на лисп она же выглядит корявенько. Многие считают это минусом лиспа, позможно, и из-за этого заканчивают его постигать, но вся его сила появляется тогда, когда огромная программа на C++, perl, java и т.п. начинает выглядить монстроподобно и все понимает что это кирдык, но делать никто не хочет, в надежде что проект закончится раньше чем монстр развалится. В то время большая программа на лиспе продолжает так же корявенько выглядить ;)

> В то время большая программа на лиспе продолжает

казалось-бы, а причем здесь С ? :)

При том, что заявлять что Си годится для больших проектов лучше всего не стоит. Лисп кстати тоже не годиться :)

> на плюсах вообще трудно найти красивый большой проект(и а плане архетектуры и в плане кода)

возмонжо что дело в том, что у большинства народу, кто осилил C++, уже не хватает времени на opensource, т.к. они участвуют в коммерческих разработках, а коммерческие разработки вам вряд-ли кто покажет, что там внутри и как, даже офишировать никто не будет "вот, наша CAD система стоимостью $10000 написана на C++!"

ЦПП ДРЯНЬ! ААА! УУ! Ух-ух-ух! На, на, получи, умри, сдохххни! В гиену огненную, в гиенну! Червям скормить!! ААААА!
Руби его, руби! Топчу, топчу, прыгаю, прыгаю!! А? А! ЦПП! Сдохни тварь! Блуээ, Блуээ, тфу, гадость, тфу, холодно, мама!
За язык его повесить, гильетенировать, лапки с клешнями засолить. Да, да, умри , умри! Подыхайй бестия!
Тараканам вместо презерватива! Плесенью его высосать, згнобить бактериям...

   \        /
    \  CCC /
     \C   C
     C\  /   +  +
     C \/      
      C \ C
     / CCC 
    /     \
   /       \ 

Mentor Graphics - Одна из лучших EDA, если не лучшая, написана на C++. Более того, много вещей в C++ добавлено именно по прозьбе программистов из MG. Читать Страуструпа "Эволюция и дизайн C++".

ну ладно назовите хотя бы один "хороший" большой проект на ++, я не могу сходу ни одного вспомнить

> далеко не несколько, надо сказать.

верно.

> В C? поподробнее пожалуста, я всегда считал, что в C операция приведения типов делается в compile time ;)

хехе, тут всё немного сложнее, чем вы думаете. если вы пишите *универсальный* контейнерный тип данных или *универсальную* ф-ю делающую операции над произвольным потоком данных, то использовать простое приведение void* к чему-либо невыгодно, тк юзеру придётся на стороне своей программы, использующей библиотеку имплементить, простите за нецензурщину, "конструктор", "деструктор" и операцию сравнения. гораздо более удобной абстракцией является void* или char* нужного размера, хранящий поле + и один или более указателей на нужные ф-ю(учитывая разношёрстность данных). т.о. образом один void*/char* хранит последовательно адреса методов и объекта. посему compile time в этом известном и широко применяемом хаке даже и не пахло =)

> но для коммерческой разработки обычно выбирают C++,

хм. по-моему выбирают уже давненьку jav'y.

> Ну а вы попробуйте, мне приходилось писать VFS подобный уровень для embedded платформ на чистом C, и знаете, много можно было-бы сделать куда быстрее, елси бы под руками оказался компилятор плюсов.

наврятли. если вы пишите под embedded существует определённый набор "правил хорошего тона", в принципе общих, как для C, так и для ++. общих потому, что если вы разрабатываете что-то низкоуровневое под "особенную" платформу, вы будете писать на c. даже если вы пишите на c++ =)

qt, kde.

первый довольно хорошо задизигнен, про имплементацию ничего не могу сказать. а второй - хз. =)

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

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

Photoshop

вы видели его сырцы?

>увольте, c делает ++ по производительности, зачем изголяться?

Это почему это? К примеру контейнеры работающие с void * (как это принято в С) работают всегда медленнее чем их аналоги, написанные на шаблонах (за примерами далеко ходить не надо, достаточно взять контейнеры из glib и STL и убедиться как "c делает ++ по производительности").

>в си не нужны шаблоны.

Если бы это было так, то таких вещей как sys/queue.h и им подобных не было. А зачем было бы извращаться, если и с void * все "быстро" работает ? :)

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

Эти твои "несколько циклов" дают то, что std::sort работает всегда быстрее qsort'а. И то, что C уделывает C++ по производительности было с твоей стороны откровенной ложью.

> http://theory.stanford.edu/~amitp/rants/c++-vs-c/
> В appendix-е есть все сорцы.

[vitaly@dhcp-lab-143 tmp]$ gcc -o test1 test1.c 
[vitaly@dhcp-lab-143 tmp]$ g++ -o test3 test3.cc 
In file included from /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/backward/ios
tream.h:31,
                 from test3.cc:5:
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/backward/bac
kward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the <X> header for the <X.h> header for C++ includes, or <iostream> instead of the deprecated header <iostream.h>. To disable this warning use -Wno-deprecated.
[vitaly@dhcp-lab-143 tmp]$ ./test1
Usage: ./test1 <array-size>
[vitaly@dhcp-lab-143 tmp]$ ./test1 1000000
   0.54
   0.54
   0.53
   0.54
   0.55
   0.55
   0.54
   0.54
   0.53
   0.53
[vitaly@dhcp-lab-143 tmp]$ ./test3 1000000
0.66
0.67
0.66
0.66
0.66
0.66
0.66
0.67
0.67
0.66

А внушали, что будет хуже в 5.3 раза. Языком пиздеть - не мешки ворочать.

> А внушали, что будет хуже в 5.3 раза. Языком пиздеть - не мешки ворочать.

Попробуйте, ради смеха, почитать ман по gcc, там есть опция -O, если вы не знали. Без этой опции никакой обьективности не будет, т.к. никакого inline-а встроенного не произойдет, и вообще, почитайте статью саму.

> Попробуйте, ради смеха, почитать ман по gcc, там есть опция -O, если вы не знали.

Да читал, читал. С -O2 разница есть, но -O6 -funroll-all-loops - это дикий бред, так программы только гентушники собирают. Остальные подозрительно даже на -O2 смотрят.

> Без этой опции никакой обьективности не будет, т.к. никакого inline-а встроенного не произойдет, и вообще, почитайте статью саму.

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

>> Попробуйте, ради смеха, почитать ман по gcc, там есть опция -O, если вы не знали.

> Да читал, читал. С -O2 разница есть, но -O6 -funroll-all-loops - это дикий бред, так программы только гентушники собирают. Остальные подозрительно даже на -O2 смотрят.

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

>> Без этой опции никакой обьективности не будет, т.к. никакого inline-а встроенного не произойдет, и вообще, почитайте статью саму.

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

Вытащите из libc-а сорцы qsort-а (что-бы был в точности такой-же), включите в тестовый пример, и померяйте, если вам кажется, что приведенные тесты не обьективны.

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

Это радует. Не радует, что не всегда десяток накрученных штук разворачивается в константу.

> Вытащите из libc-а сорцы qsort-а (что-бы был в точности такой-же), включите в тестовый пример, и померяйте, если вам кажется, что приведенные тесты не обьективны.

Я полагаю, что нужно вытаскивать sort из stl и затаскивать в препроцессор, чтобы было объективно. Впрочем, найденный qsort на препроцессоре немного сливает test2.

Только вот с сортировкой строк такой финт ушами уже не проходит.

> Я полагаю, что нужно вытаскивать sort из stl и затаскивать в препроцессор, чтобы было объективно.

В том то и дело, что нет. Проепроцессор это костыль, а шаблон - нет.

>шаблон - нет

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

Ты меня опередил :)

> Если бы это было так, то таких вещей как sys/queue.h и им подобных не было. А зачем было бы извращаться, если и с void * все "быстро" работает ? :)

на самом деле не нужно. у си не та сфера, для которой нужна всеобщая универсализация. си - это кроссплатформенный ассемблер((ц) профессор), имеющий детерменированную нишу(в отличие от ++). пример с void* был приведён в кач-ве a) пояснения b) примера того, что на c можно реализовать псевдо ооп, универсализацию, да и вообще что угодно.

но всё это к чёртям не нужно.

> Эти твои "несколько циклов" дают то, что std::sort работает всегда быстрее qsort'а.

ну-ну. давайте уберём универсализацию и заточим qsort под определённый тип данных, и посмотрим, кто кого сделает ;)

> И то, что C уделывает C++ по производительности было с твоей стороны откровенной ложью.

да ну? допустим у вас std::sort. мегаписюкатый и быстрый. замечательно. вы его используете в своей программе. тоже замечательно. но ваша программа обрастает классами, dynamic_cast'ами, наследованием и тд и тп. всё это идёт в существенный ущерб скорости. или вы не будете всё это использовать? если нет, то тогда зачем нужнен c++? =)

> Проепроцессор это костыль

обоснуйте.

>> Проепроцессор это костыль

> обоснуйте.

Докажите обратное. Даже сами создатели C считают препроцессор костылем. Сейчас нет времени на подробные обоснования, но самый простой пример -- макросы препроцессорные весьма опасны в использовании.

>> Эти твои "несколько циклов" дают то, что std::sort работает всегда быстрее qsort'а.

> ну-ну. давайте уберём универсализацию и заточим qsort под определённый тип данных, и посмотрим, кто кого сделает ;)

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

> да ну? допустим у вас std::sort. мегаписюкатый и быстрый. замечательно. вы его используете в своей программе. тоже замечательно. но ваша программа обрастает классами, dynamic_cast'ами, наследованием и тд и тп. всё это идёт в существенный ущерб скорости. или вы не будете всё это использовать? если нет, то тогда зачем нужнен c++? =)

Далеко не все идет в ущерб скорости, если грамотно использовать.

> Далеко не все идет в ущерб скорости, если грамотно использовать.

вы хотите сказать, что наследование rtti и виртуальные методы не дают оверхеда в производительности?

> Докажите обратное. Даже сами создатели C считают препроцессор костылем.

источник в студию. если вы про k&r "c programming language", то препроцессор там отнюдь не называют костылём, а призывают очень осторожно использовать *макроопределения*. препроцессор - это не костыль, это необходимость.

btw: шаблоны - это фактически тоже "препроцессор", только безопасный. костыль это али нет?

> Сейчас нет времени на подробные обоснования, но самый простой пример -- макросы препроцессорные весьма опасны в использовании.

это утверждение из области "указатели - костыль! почем? ну как же, пользоваться ими не безопасно."

> ну-ну. давайте уберём универсализацию и заточим qsort под определённый тип данных, и посмотрим, кто кого сделает ;)

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

>dynamic_cast'ами, наследованием и тд и тп. всё это идёт в существенный ущерб скорости. или вы не будете всё это использовать? если нет, то тогда зачем нужнен c++? =)

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

Кстати ООП в чистом Си что уже реализуется без ущерба в скорости? С ним самым, да еще и с гемороем при кодировании.

Если у тебя виртуальный метод = o(основные_вычисления), что бывает очень часто, то фактически никакого оверхеда нет (он составляет доли процента).

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

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

>Кстати ООП в чистом Си что уже реализуется без ущерба в скорости? С ним самым, да еще и с гемороем при кодировании.

уважаемый, зачем писать ООП на "чистом Си"? ну если очень хочется/надо то можно и без существенного ущерба в скорости и без гемороя. примеры на то есть

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

так, давайте вы внмательно перечитайте то, о чём я писал. с - *кроссплатформенный ассемблер*. это суть ниша данного языка. в системщине *нужно* оптимизировать, юзать simd'ы, altivec, etc. там нет никакой универсализации, там есть заалигненные по 2^n бонде куски памяти, там есть аццкий дебаггинг и борьба за каждый цикл процессорного времени. универсализация with c приемлема, например, в ядре, тк как минимум система написания драйверов должна быть удобной и быстрой.

btw: хотя никто так и не ответил мне насчёт нисши c++, на работе в разгаре аццкого флейма на эту тему меня просветили. ниша с++ - game development. а это очень не маленькое пространство.

> Кстати ООП в чистом Си что уже реализуется без ущерба в скорости?

ещё раз говорю, ооп на си реализуемо, но оно не нужно данному языку, тк оно будет реализовано с ущербом производительности. *не* нужно. это то же самое, что реализовавывать "псевдо fp" на плюсах и писать в данной парадигме. но это мракобесие.

> Если у тебя виртуальный метод = o(основные_вычисления), что бывает очень часто, то фактически никакого оверхеда нет (он составляет доли процента).

1) "практически нету" == есть.

2) виртуальные методы чрезвычайно часто используют не по делу, отнаследовав n классов, от которых наследуются ещё m классов и каждый из них делает не фиговую работу в virtual методе. ещё можно лицезреть огромное кл-во кода, в котором используют нелогичесное в данной ситуации наследование вместо явного деленирования. в итоге получаетя тормоз чистой воды.

Ещё одна нища c++ - всякие cad, eda системы. И вообще c++ нужен там, где нужна высокоуровневость с одной стороны и жёсткая оптимизация с другой. То есть когда, java/.net/python - слишком медленно, а c - слишком сложно.

s/нища/ниша

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

А реализация функциональности, аналогично виртуальным методам, на чистом С, работает сильно быстрее, да? rtti - не дает такого огромного оверхеда, а под наследованием, вы уточните, что имеете в виду, если просто наследоватся от класса без виртуальных методов, то в итоге все тупо соптимизируется, а если с виртульальными методам -- см выше.

> источник в студию

Книга "практика программирования" от создателей C.

> 2) виртуальные методы чрезвычайно часто используют не по делу, отнаследовав n классов

Вот это и называется "надо грамотно использовать".

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

понятно что рано или поздно заточить можно все что угодно, но зачем когда уже есть готовое?

>уважаемый, зачем писать ООП на "чистом Си"?

спроси об этом разработчиков ядра и gtk/gnome

>2) ....

Это уже вторая крайность. Не люблю фанатиков, орущих, что ООП не нужен и фанатиков, пытающихся делать из ООП в каждой жопе затычку и писать на нем hello world'ы.

> это утверждение из области "указатели - костыль! почем? ну как же, пользоваться ими не безопасно."

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

class something { ... int max(); ... }

значете почему? Потому что в Apple-овских хедераз определен макрос max.

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

Еще одно ииз самых главных отличий -- препроцессор не поддается отладке, а шаблоны прекрасно отлаживаются :)

Кто-нибудь знает как писали, например, queue.h? Я предполагаю, что вначале написали по человечески в виде функций, а когда все заработало загнали в шаблон. А вот когда вдруг в этом шаблоне обнаружится глюк, то геморой при отладке обеспечен :)

> Ещё одна нища c++ - всякие cad, eda системы.

Самый мощный CAD/CAE/CAM современности - Unigraphics - написан на Си. Разратывается, о, боги, с 1963-го года. Вот вам пример огромного проекта на Си, который живее всех живых, и недостижимо лучше конкурентов.

> а c - слишком сложно.

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

> значете почему? Потому что в Apple-овских хедераз определен макрос max.

А если вы в своём классе начнёте использовать такие простые и понятные названия, как list, queue и т.п., то проблемы у вас могут начаться и в плюсах. Всё это, конечно, поддаётся детекции, но на неё нужно тратить время программиста, на что обычно фанаты плюсов внимания не обращают.

> Не люблю фанатиков, орущих, что ООП не нужен

ООП != C++. В C++, к тому же, ООП не самого лучшего качества.

> Книга "практика программирования" от создателей C.

враньё. циату в студию. я, кажется, упомянал *о чём именно* коворили k&r по поводу макросов. они не говорили, что это костыль, они констатироали, что их нужно использовать осторожно. не более.