>Дополнительного веселья добавляет передача по ссылке, когда глядя в код, >невозможно определить -

Глядя в код C++, это определяется тривиально.

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

Меня, например, всегда потрясали объемы... внушает.

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

А что происходило с разработчиками на forth ? (поиск Титаника, управление телескопами, ...)

Там переопределение семантики - нормальное явление. В этом, даже, есть своя красота.

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

forth - спасет отца русской демократии. Там конечная реализация проекта - и есть специализированный язык. (Вспомните PostScript, это прямой потомок forth`a).

> Зачем все это нужно В ОДНОМ языке?

Действительно... а задача какая?

> forth - спасет отца русской демократии.

Ты опоздал. Антихрист уже всем популярно разъяснил, что форт плохой, т.к. в нем нет GC и pattern matching. И ищо патамучта Мур - маньяк, вот.

День добрый! Решил вствить свои 5 копеек по поводу Форта. К сожалению у этого языка (по крайней мере в его классических реализациях) есть серьезные недостатки. На вскидку могу привести следующие: 1. Нет возможности "скрыть" константы, переменные, слова в какой-либо программной единице (к примеру, файле). Т.е. пространство имен является общим и из-за этого или возникают конфликты имен или используеются длинные имена. 2. Если необходимо подправить какое-либо слово, то приходится разбирать его работу по шагам с самого начала чтобы знать, какие переменные лежат на стеках (их два) в каждой точке слова.

Вот, это вещи, которые вызывали у меня раздражение при написании программ на Форте :)

> в нем нет GC и pattern matching.

Нда, проблема... Что же делать-то ???

А самому написать - не судьба?

P.S. Когда-то мне понравились реализации на forth Паскаля (примитивного, но, все-таки), Ассемьлера (К580) и Пролога (!). Оно того стоило, чтоб почитать и попробовать разобраться, как оно работает... А размеры исходных кодов... крохотные... н-да...

но, вам, наверное, этого не понять... после С++ и Java. Вам же платят за количество строк ?

> И ищо патамучта Мур - маньяк, вот.

н-да, действительно...

Ввести в свой язык понятие контекстных словарей и легкую реализацию ООП-принципов ЗАДОЛГО до с++ (forth на год младше С)... это не простительно.

в С++ нет легкой реализации ООП-принципов!

ну где, где Антихрист??? Я жду... без него ниприкольна как-то в такой-то ветке!

Это не реклама! Так... ностальгия.

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

А "контекстные словари" на что ? Представляешь: изменилась сущность - переключился на словарь для этой сущности...

А, типа, "лямбда" реализовать проблема ?

(без`имянные участки памяти, с доступом по адресу, в теле "слова")

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

Кстати, а в других языках по-другому? За то - OpenSource, с самого рождения !

P.S. Тогда, уж - "польская нотация" и явная работа со стеками виноваты...

P.P.S. Это не реклама.

:-)

> (без`имянные участки памяти, с доступом по адресу, в теле "слова")

уп-с... пардон... не поймите меня правильно :)

"(без`имянные участки памяти, с доступом по адресу, выделяемые и освобождаемые динамически в словаре или вне его, для каждого исполнения "слова")"

...чтоб не было проблем с трактовками... программисты, все-таки, собрались.

:-)

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

Например, вот: в шитом коде, в контексте, ставишь метку (пустое слово), а затем перенастраиваешь "ссылку на предыдущее слово" у нужного слова на эту метку, и - (вуа-ля!) интерпретатор этих слов уже не увидит (а cfa используются). Что сложного ?

Низкая эффективность, разумеется, по сравнению с С. Жабка и не претендует. Форматная строка - она и в С++ есть. И, кстати, чем многословно объяснять, какой именно формат я хочу - уж лучше я %-6.2f напишу.

Про конструкторы копирования уже объяснили. Никогда не приходилось Вам полдня искать багу, связанную с тем, что в этом конструкторе кто-то забыл "&"? Любопытные вестчи получаются.

Вопрос о переопределении - действительно религиозный. Но меня ЛИЧНО очень напрягает, когда я должен держать в голове смысл оберации a+b для каждого типа класса а (я уже не говорю про то, что полиморфизм у этой операции - по первому параметру, а если хочется сделать эту функцию "виртуальной и по второму параметру тоже?).

Кстати, слово virtual требует вообще отдельных песнопений. Метод - еще понятно. Но вот наследование - это ж просто страшное оружие, направленное против разработчика. Если я произвожу классы D1 и D2 от класса B, я должен подумать - а не захочет ли кто-нибудь когда-нибудь унаследовать от них обоих. И сколько объектов класса B должно при этом быть. И если вероятность такого события не 0 - на всякий случай, сделаю их виртуально наследующими. Еще один щелчок по носу производительности. Концептуально - я на этапе разработки базовых классов должен предвидеть все мыслимые способы их использования. И если ошибусь (сделаю наследование невиртуальным - каково оно по умолчанию) - тоже буду ловить некоторое количество интересных ошибок.

Exceptions - вообще достаточно дорогое удовольствие, если реализовано честно. Но С++, имея имидж быстрого языка, провоцирует на использование этого дорогого механизма - не предупреждая - товарищи, это может быть очень и очень дорого. А Java и не претендует на скорость. Про ее скорость мы все знаем. Кстати, интересно было бы замерить скорость рефлексии в жабке и в С++. Не удивлюсь, если жабка быстрее:)

Лепят на любых языках. Не все языки провоцируют. Если многие по старинке пишут Vector вместо ArrayList - это не бага, это просто торможение (кстати, дающее взамен защищенность от многопоточного доступа - даже если автор об этом и не думал:). А вот случайно опущенный знак "&" действительно может стать причиной баги. Или пропушенное где-то в недрах библиотеки классов слово virtual.

>Форматная строка - она и в С++ есть

Это только в плюс C++ :)

>чем многословно объяснять, какой именно формат я хочу - уж лучше я %-6.2f напишу.

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

>Никогда не приходилось Вам полдня искать багу

Нет. Такие глупые ошибки на раз отлавливаются компилятором.

> Но меня ЛИЧНО очень напрягает, когда я должен держать в голове смысл оберации a+b д

А меня лично напрягает, что для сложения двух double я должен бы писать

double res = a + b;

а при сложении двух real --

real res; add_real(a,b,res);

>Кстати, слово virtual требует вообще отдельных песнопений.

Особенно в java, где все вызовы по умолчанию виртуальны.

>Но вот наследование - это ж просто страшное оружие, направленное против разработчика.

Не нравится -- не пользуйся, разве не так? Это просто _дополнительная_ возможность. За которую, в отличие от всяких чистаабъектных языков, никакими накладными расходами платить не надо.

> Концептуально - я на этапе разработки базовых классов должен предвидеть все мыслимые способы их использования.

Это уже софистика. Код создается не "во вселенную", а в совершенно конкретных условиях и в совершенно конкретных целях. Допустимость DAG-ов в иерархии классов всегда можно заранее оговорить.

> Но С++, имея имидж быстрого языка, провоцирует на использование этого дорогого механизма -

Пмсм плюсовые исключения крайне редко используются как механизм передачи управления, и в 99 случаях из 100 используются как механизм для реакции на критическую ошибку. Когда такая ошибка случилась -- спешить некуда :)

>Лепят на любых языках. Не все языки провоцируют.

Все языки провоцируют, только на разные вещи. С++ провоцирует на некоторые ошибки. Java провоцирует на _максимально_неэффективный_ код.

>> ... я уже не говорю про то, что полиморфизм у этой операции - по первому параметру, а если хочется сделать эту функцию "виртуальной и по второму параметру тоже?.

Поищи в книжках про идиому двойной передачи параметров.

В качестве хинта:

T1 f(const T2 &x) const {
return x.f(*this);
}

А от того, как эта функция называется: "f", или "operator+" суть ведь не меняется.

Хорошо, отнесем вопрос с форматным выводом к вопросом вкуса. Многословность (С++) vs неочевидность (С).

Про "такие глупые ошибки" - не знаю. В то время, когда я работал на С++, компилятор пропускал конструктор с параметром объект.

На мой вкус, в ОО языке умолчание о виртуальных методах осмысленно. Но это вопрос вкуса. Я просто имел в виду, что одно и то же слово имеет разный смысл в разных контекстах (кстати в простом C этим грешит слово static).

За виртуальное наследование платить надо. Во-первых, не забыть вставить в код это слово. Во-вторых, в процессе выполнения выполнять одно лишнее разыменование.

Конечно, код создается в конкретных целях. Просто разработчик базовой библиотеки иногда может непредусмотреть целей тех, кто эту библиотеку использует. В рамках замкнутого приложения это все не смертельно - а если вы разрабатываете платформо-образующий API?

Как именно использовать исключения - об этом много книг написано. Но торможения это не отменяет. И с С++, и в жабке. Кстати, я помню чудное мгновение, когда в борландовском компиляторе С++ они были реализованы через макросы. И, конечно, о вызове деструкторов и речи не шло. Но это так, исторический экскурс. Я не против торможения в этом месте - деваться-то некуда. Я против того, что язык, у которого БАЗОВЫЕ КОНСТРУКЦИИ могут тормозить - считался таким же быстрым и эффективным, как язык, у которого цена каждого ключевого слова - минимальна.

Java действительно провоцирует неэффективность. Это правда. Но лично я между неправильной и неэффективной системой выбираю последнюю. Зато я чувствую себя гораздо больше "в танке". А процессоры и память нынче дешевы...:) А С++... он не дает мне чувства защищенности, как жабка. Он обманывает, утверждая, что "все будет хорошо" - а сам ставит подножки в некоторых местах. С - честнее. Там человек работает почти на асме - и несет всю полноту ответственности (кто-то сказал, что С - это асм pdp-11, вообразивший себя языком высокого уровня - в этом смысле С++ - это ОО асм:).

А ещё Антихрист гойворил, что Joy - хороший. И врождённые недостатки Форта в нём таки отсутствуют. Так что - рекомендую.

А типа про OOP/OOD и generic programming я ещё таки напишу...

Я неправильно задал вопрос. Конечно, интересует виртуальность сразу по обоим параметрам. И по третьему, и по четвертому (я не говорю обязательно про операторы - про функции вообще).

Написать? Велькам. Пиши. Чтоб работало со всей памятью, доступной Форту, по алгоритму stop'n'copy->mark'n'sweep. Я вот не вижу дешевого решения. Увы... Pattern matching написать несколько проще - то есть, в принципе можно. Но - тоже никто этого не сделал. Однако же - сама по себе концепция Форта - оченно даже заслуживает внимания. А до чего её довели в настоящее время - смотреть на Joy, он хороший.

Хороший компромисс между удобством перегрузки и type safety/читабельностью - в хаскеллёвых type classes. Рекомендую ознакомиться - идейка заслуживающая внимания.

>В то время, когда я работал на С++, компилятор пропускал конструктор с параметром объект.

Это уже довольно давно не так.

>За виртуальное наследование платить надо.

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

>а если вы разрабатываете платформо-образующий API?

С++ -- это не язык для платформо-образующих API. Уродство MFC в частности и громадных иерархий с Мой-любимый-префикс-object в корне вообще имхо достаточно видно.

>Как именно использовать исключения - об этом много книг написано. Но торможения это не отменяет.

Опять за рыбу деньги. Торможения по отношению к ЧЕМУ? По отношению к языку, у которого такой возможности _вообще_нет_?

>считался таким же быстрым и эффективным

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

>А процессоры и память нынче дешевы...:)

А машина должна работать, а не заниматься бесполезными разыменованиями :)

>А С++... он не дает мне чувства защищенности, как жабка.

А мне он дает чувство предсказуемости, в отличие от жабки :)

>Я просто имел в виду, что одно и то же слово имеет разный смысл в разных контекстах

Кстати, смысл один и тот же.

Ну, то, что компиляторы ушли вперед - это радует. Только что проверил - да, g++ ругается. Уря.

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

Можно я на стенке напишу большими буквами, что С++ - не язык для платформо-образующих API? А то народ тут придумывает - то MFC, то QT, то Gecko... Собственно, после консенсуса по этому поводу нам с Вами и спорить-то почти не о чем. Да, для многих приложений С++ годится. Если квалификация программеров позволяет успешно обходить все его грабли, если он им нравится (может, еще есть парочка "если").

А если он позволяет писать еще и небыстрый и неэффектиный код? И иногда провоцирует? Это быстрый и эффективный язык? Пример мы видели выше - вместо того, чтобы просто использовать const char* - взяли и создали string. И в терминах С++ - это был правильный ход.

А что непредсказуемого в жабке, позволю спросить? Разве что момент вызова сборщика мусора. И то - его можно позвать насильно:)

Смысл один и тот же (доступ через указатель) - только если программист знает, КАК это реализовано. А семантика - разная. В случае функции это указание на полиморфизм. В случае наследование - указание на объединение объектов базовых классов при множественном наследовании. Если забыть про реализацию, я не вижу общего смысла.

2Antichrist (*) (21.11.2003 18:29:04)

> Чтоб работало со всей памятью, доступной Форту, по алгоритму stop'n'copy->mark'n'sweep. Я вот не вижу дешевого решения. Увы... Pattern matching написать несколько проще - то есть, в принципе можно. Но - тоже никто этого не сделал.

http://www.forth.org.ru/~day/day2309.rar

Посмотри hpOOP & jOOP ... Правда, для win* и старовато, но информативно...

Поновее:

http://sourceforge.net/project/showfiles.php?group_id=17919&release_id=18...

или тут:

http://www.enet.ru/win/cherezov/sp-forth.html

Если интересно, найдешь.

можешь посмотреть еще и http://www.forth.ru но, этот, к сожелению, уже "не шевелится"...

:-)

"б ЯНБЕПЬЕММН МЕОПЕДЯЙЮГСЕЛШУ ОНЯКЕДЯРБХЪУ РПХБХЮКЭМНЦН БШГНБЮ ТСМЙЖХХ, ЙНРНПЮЪ Б ЙЮВЕРЯБЕ ЮПЦСЛЕМРЮ ОПХМХЛЮЕР НАЗЕЙР, МЮОПХЛЕП." оНЯКЕДЯРБХЪ БОНКМЕ ОПЕДЯЙЮГСЕЛШ - я.лЕИЕПЯ, щТТЕЙРХБМНЕ ХЯОНКЭГНБЮМХЕ я++, оПЮБХКН 22. оПЕДОНВХРЮИРЕ ОЕПЕДЮВС ОЮПЮЛЕРПНБ ОН ЯЯШКЙЕ ОЕПЕДЮВЕ ОН ГМЮВЕМХЧ. "дНОНКМХРЕКЭМНЦН БЕЯЕКЭЪ ДНАЮБКЪЕР ОЕПЕДЮВЮ ОН ЯЯШКЙЕ, ЙНЦДЮ ЦКЪДЪ Б ЙНД, МЕБНГЛНФМН НОПЕДЕКХРЭ - АСДЕР КХ ОПХ БШГНБЕ ТСМЙЖХХ ОЕПЕДЮБЮРЭЯЪ ЯЮЛ НАЗЕЙР ХКХ ЕЦН ЙНОХЪ." еЯКХ РШ ЯЛНЦ ОПНВЕЯРЭ Х ОНМЪРЭ ОПЮБХКН ╧ 22 РН Ъ СБЕПЕМ ВРН ЯЛНФЕЬЭ НРЙПШРЭ Б ЯБНЕЛ КЧАХЛНЛ IDE ГЮЦНКНБНВМШИ ТЮИК Х ОНЯЛНРПЕРЭ ЙЮЙ НАЭЪБКЕММЮ ЩРЮ ТСМЙЖХЪ (ГЮНДМН Х ОПХБЕЯРХ ЕЕ ЕЯКХ МЮДН Б ЯННРБЕРЯБХЕ Я ЩРХЛ ОПЮБХКНЛ)

"б ЯНБЕПЬЕММН МЕОПЕДЯЙЮГСЕЛШУ ОНЯКЕДЯРБХЪУ РПХБХЮКЭМНЦН БШГНБЮ ТСМЙЖХХ, ЙНРНПЮЪ Б ЙЮВЕРЯБЕ ЮПЦСЛЕМРЮ ОПХМХЛЮЕР НАЗЕЙР, МЮОПХЛЕП." оНЯКЕДЯРБХЪ БОНКМЕ ОПЕДЯЙЮГСЕЛШ - я.лЕИЕПЯ, щТТЕЙРХБМНЕ ХЯОНКЭГНБЮМХЕ я++, оПЮБХКН 22. оПЕДОНВХРЮИРЕ ОЕПЕДЮВС ОЮПЮЛЕРПНБ ОН ЯЯШКЙЕ ОЕПЕДЮВЕ ОН ГМЮВЕМХЧ. "дНОНКМХРЕКЭМНЦН БЕЯЕКЭЪ ДНАЮБКЪЕР ОЕПЕДЮВЮ ОН ЯЯШКЙЕ, ЙНЦДЮ ЦКЪДЪ Б ЙНД, МЕБНГЛНФМН НОПЕДЕКХРЭ - АСДЕР КХ ОПХ БШГНБЕ ТСМЙЖХХ ОЕПЕДЮБЮРЭЯЪ ЯЮЛ НАЗЕЙР ХКХ ЕЦН ЙНОХЪ." еЯКХ РШ ЯЛНЦ ОПНВЕЯРЭ Х ОНМЪРЭ ОПЮБХКН ╧ 22 РН Ъ СБЕПЕМ ВРН ЯЛНФЕЬЭ НРЙПШРЭ Б ЯБНЕЛ КЧАХЛНЛ IDE ГЮЦНКНБНВМШИ ТЮИК Х ОНЯЛНРПЕРЭ ЙЮЙ НАЭЪБКЕММЮ ЩРЮ ТСМЙЖХЪ (ГЮНДМН Х ОПХБЕЯРХ ЕЕ ЕЯКХ МЮДН Б ЯННРБЕРЯБХЕ Я ЩРХЛ ОПЮБХКНЛ)

> при этом упоминание термина "алгебра Каца-Муди", вызывает у них > приступы нездорового смеха.

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

Внимательнее, пожалуйста. Одного mark'n'sweep мало - ещё раз читаем условия. А ведь я ещё не потребовал компактифицирующего stop'n'copy...

Уважаемый у Вас происходит типичная подмена понятий - Вы путаете теплое с мягким.

Кто вам в критических ко времени выполнения участках кода запрещает пользоваться char*. Я думаю никто. И также не запрещено, там где это не критично воспользоваться string'ом, поелику это иногда удобно.

Работа с поинтерами вообще удобна в применении к наследованию и виртуальности. При грамотном подходе сильно облегчает жизнь.

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

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

Потом мы же не будем забывать о средствах отслеживания корректности работы с памятью. Bounds Checker например бод винды замечательно мониторит код. и ещё раз надо вспомнить о грамотном проектировании.

И когда говорят, что это дорого, то сильно ошибаются. Дороже себе встанет переписывать куски кода. Доказано.

Есть конечно ситуации когда надо быстро и ещё быстрее, но лучше подумать неделю и спасти при этом квартал.

> Я имел в виду мехмат МГУ, конечно.

ты механик.. Мы с Санычем и Мурычем смотрим на тебя с высока. Мы Каца-Муди видели.

s/с в/св/

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

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

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

Буду ли я платить "виртуальным" вызовом за point.getX(), или все же это удовольствие встроится? Сможет ли компилятор оптимизировать через границу этого вызова? Где будет размещен объект? И т.д. и т.п. Короче, я не могу прикинуть, сколько мне будет стоить та или иная операция.

>При этом использовать ОО фичи этого языка нужно осторожно.

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

>И помнить про спрятанную цену.

Непонятно, почему цена -- спрятана? Скорее, надо понимать, что за собой влечет использование той или иной фичи. Это нетрудно. Но это универсальное требование опять же.

C++ apology

Я плакаль (тм). Мне понравилось по поводу "свысока". Есть люди, которые закончили педагогический посредственно, но потом сделали столько и так качественно, что мне приходится смотреть на них снизока ;). Впрочем, я помню мехматовский снобизм - сам болел (и не только этой глупостью). Мой профессор, кстати, окончил аспирантуру MIT, в котором еще больший снобизм, так вот он тоже здоров. Зато я лично знаю много больных отличников с мехмата и физтеха, которые до сих пор программируют на клиппере и радуются трем с половиной сотням баксов зарплаты, грохая все свободное время на виртуальные стрелялки друг с другом (забыл как называется игрушка, типа ДУУМА, но можно друг в друга стрелять). Кое кто из них до сих пор учит меня про то, как интегрировать дифуры.

;) И все же С++ рулит. Но не потому, что он лучше всех (я думаю, что лучше или хуже может быть лишь относительно того, что надо делать и кому это надо делать), а потому, что мне на нем удобнее всего работать. Мне он кажется простым и ясным. Исключениями я вообще не пользуюсь, наследование использую довольно редко. Слово виртуал вообще написал всего два раза. А вот возможность писать абстрактные ИСПОЛНИТЕЛИ (кто учился у Лебедева, тот понял), возможность писать одну и ту же функцию под разные аргументы, более широко: пользоваться шаблонами и переопределять операции (это вообще жутко удобно) - то что я ценю в этом языке. Математики, это же колоссальное удовольствие, создавать своих собственных существ, в которых определены их свойства, которые общаются с другими при помощи сообщений. Вы же можете придумать любой платоновский класс, скажем корову, потом класс травы, класс волков, наплодить объектов и пустить пастись. И просто смотреть. И наслаждаться. Для слабонервных можно убрать волков или запретить им есть. И лев возляжет...

Когда же появились хорошие библиотеки, начиная со встроенной СТЛ (кто-то здесь уже упомянул отличный boost) и кончая qt, то зачем мне еще что-то? Код становится как книга, когда читаешь, не видя букв, а наблюдая действия, как в кино.

Это все лирика. Говоря же по существу, я полностью согласен с теми, кто говорит, что С++ обладает возможностями, которыми вы можете пользоваться, а можете и нет. Я готов спорить, что 90 процетов упертых сишников, уверенно ставят два слеша в качестве комментариев. Еще 70 процентов долбят ключевое слово конст, вместо макросов. Принимая маленькие частности, что же вы бодаетесь с другими дополнениями?

На С++ можно писать также как и на С, только это суживает возможности.

Вообще - осторожность полезная. Я в данном случае имел в виду вполне конкретную вещь - понижение производительности в случае "хорошего" (с т. зр. ОО) стиля программирования - по сравнению с "плохим" (в смысле - классическим С-шным. Пример - тот самый string vs const char*. С жабой все просто - там все примерно одинаково медленно:) А скажите, чем еще может быть ключ в _универсальном_ контейнере, если не объектом? А реализации неуниверсальных контейнеров с ключами в виде целых чисел - валялись где-то в инете.

Ну, про цену действительно нужно помнить всегда. Просто в С++ стОимость разных конструкций очень различается - я говорю именно про это. Выход из цикла по сравнению переменной или по искл. ситуации - в С++ отличаются очень сильно. В этом смысле, как мне кажется, жабка более однородна - там все примерно одинаково дорого:) Я говорю "спрятанная" потому, что люди без оговорок произносят "С++ так же быстр, как С". Этот вот имидж и прячет реальную цену некоторых конструкций...

У Вас получилась очень красивая апология ООП. Особенно про "собственные существа" и "платоновские классы" (правда, у Платона это, вроде, были "идеи" - но я минимум сдавал давно, могу ошибиться). Действительно красиво.

А два слеша я ставлю, это правда. И консты иногда применяю (правда, не вместо макросов). Это делает меня программистом на С++?:) И Вы уверены, что сложная объектная модель С++ - это "дополнение" к двум слешам?:)

Мы же уже 10 раз сказали - да, С++ может быть С. Но обсуждать-то интересно С++ во всей его ОО мощи, необузданной и дикой. Впрочем, наверное, уже даже не очень интересно. Уже все косточки перемыли.

>А скажите, чем еще может быть ключ в _универсальном_ контейнере, если не объектом?

Универсальный контейнер может (и должен!) выражаться параметризованным типом. В терминологии С++ -- шаблоном. Остальные реализации универсальных контейнеров пмсм просто не имеют смысла имхо.

> этом смысле, как мне кажется, жабка более однородна - там все примерно одинаково дорого:)

Консенсус :)

Параметризованные типы Вам будут в следующей жабке. Хотя _в_реализации_ это все равно будет делаться через обьекты. Если я не ошибаюсь. Просто примитивные типы - уж очень специальная вещь. Правда, если учесть, что в следующей жабке (или позже) обещают автобоксинг - синтаксически разницы никакой не должно быть. Устраивает?

C++ apology

Нет, я не думаю, что ОО в С++ - это дополнение к двум слешам. Но С компиляторы могут на слеши ругаться. Едят, но ругают ;)

А для чего консты применяете? В параметрах функций?

Платоновские же классы - это идеи, конечно ;) Но мне так показалось точнее сравнение, чтобы потом явно классы и идеи не сопоставлять. Неявное приведение типов, типа.

gcc на слеши не ругается. А из остальных меня только javac & jikes интересуют (а они, кстати, тоже не ругаются:)

Угу. В параметрах. И просто в переменных. Просто дурацкая привычка из жабы - везде, где можно, объявлять переменные final:)

Неявное приведение платоновских идей к классам - это сильно! Надо будет это дело обдумать отдельно:)

2 Svu: А что значит "Виртуальность по параметрам"?
"Liskov substitution principle" за это не катит?

Спрошу в ответ: а что значит "виртуальность по первому параметру"? Если у Вас есть базовый класс с виртуальной функцией, есть указатель на базовый класс (который может указывать на какого угодно потомка) - и Вы вызываете эту функцию по этому указателю, будет вызвана функция именно дочернего класса, реального класса объекта (ну или где там ближе всего к дочернему классу определена). А теперь попробуйте это расширить на несколько параметров.

Есть у вас (синтакс мой собственный, скорее жабский, чем С++):

virtual void eat( Predator this, Animal b ) - функция "базовая"

virtual void eat( Predator this, Sheep b ) - первая дочерняя реализация - кушать овец удобнее ею.

virtual void eat( Wolf this, Animal b ) - еще одна реализация, уже специфицирующая особенности волка

virtual void eat( Wolf this, Sheep b ) - совсем такая конкретная функция. Годится толко для волков, кушающих овец

И есть у меня Predator p, Animal a; И я хочу вызвать функцию, которая бы была наиболее корректной для данной пары объектов. И чтобы не заниматься выяснением, не овца ли a. И не волк ли p (это, кстати, С++ умеет - виртуальность по первому параметру в нем есть). Да, сразу скажу - из поп-языков по честному этого не делает никто, насколько я знаю. Разве что в С можно организовать такую конструкцию. Но в С все можно:)

И при чем тут принцип Лискова? Конечно, близко - но, мне кажется, не о том...

Вам, товарисч, математическая красота приплюснутых ссей мнится исключительно от незнакомства с более другими языками - в том числе и с теми, откуда идеи в C++ были спёрты. Крайне рекомендую пройтись по этому списку: Erlang (раз уж идеология message passing так в душу запала), Haskell (как идеал математической строгости и красоты), Ocaml (как компромисс промеж математической красотой и практической индустриальной применимостью), Joy - как интересная игрушка, Tcl - как супер-средство метапрограммирования, которому сяплюсатая с её детсадовскими темплейтами и в подмётки не годится, Brainfuck и Unlambda - просто так, Occam - за тем же, что и Erlang, Refal - из корпоративной солидарности и почтения к отцам-основателям. Не имея представления об этих языках, хвалить C++ - просто подло и гнусно.

Где ты в словах "мы Каца-Муди видели" усмотрел снобизм? -- это ирония:)

> ;) И все же С++ рулит. Но не потому, что он лучше всех (я думаю, > что лучше или хуже может быть лишь относительно того, что надо > делать и кому это надо делать), а потому, что мне на нем удобнее > всего работать. Мне он кажется простым и ясным. Исключениями я > вообще не пользуюсь, наследование использую довольно редко. Слово > виртуал вообще написал всего два раза. А вот возможность писать > абстрактные ИСПОЛНИТЕЛИ (кто учился у Лебедева, тот понял), > возможность писать одну и ту же функцию под разные аргументы, более > широко: пользоваться шаблонами и переопределять операции (это > вообще жутко удобно) - то что я ценю в этом языке. Математики, это > же колоссальное удовольствие, создавать своих собственных существ, > в которых определены их свойства, которые общаются с другими при > помощи сообщений. Вы же можете придумать любой платоновский класс, > скажем корову, потом класс травы, класс волков, наплодить объектов > и пустить пастись. И просто смотреть. И наслаждаться. Для > слабонервных можно убрать волков или запретить им есть. И лев > возляжет...

ну это вообще детский сад:) Антихрист не высказался в пердыдущем поцтинге грубее только потому что дети от 2 до 5 так трогательны:)

Ого! Все развлекаетесь?

>Можно я на стенке напишу большими буквами, что С++ - не язык для
>платформо-образующих API?

Нельзя. Что подумают про Вас в M$ c их COM'ами и DCOM'ами подавляющее
большинство которых сделано на C++?

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

>А если он позволяет писать еще и небыстрый и неэффектиный код?

Важно что он ПОЗВОЛЯЕТ писать быстрый и эффективный код.
Если кодер не умеет - долой такого кодера.

>сборщика мусора. И то - его можно позвать насильно:)

Вы что, решили перехватить эстафету у Серожи, у которого в Lisp'е нет
closures ? Позвать то его можно, да вот придет ли?


Captain

"виртуальность по первому параметру"? Ес

Это называется множественная диспетчеризация.

>з поп-языков по честному этого не делает никто, насколько я знаю.
Уж не знаю поп он или нет, но CLOS это умеет.

Captain

Re:

> Кстати, лет 7 назад один коллега произвел сравнение скорости вывода cout << и printf

Я проверял. И не семь лет назад, а два месяца. И не на убогом C++ от борланда, а на живом gcc-3.2+ и GNU STL. Разница в скорости вывода примитивов (ну, то есть, например, float и int) при выключенной "синхронизации с stdio" - от двух до семи раз. В пользу printf. О бустовом format'е я и не говорю, я просто его не дождался (делались то ли 10K, то ли 100K итераций с выпихиванием в /dev/null)

Re:

Блин... за что на меня анонимусы обзываются? :((

Да, понемножку языками чешем:)

Насколько я знаю, и COM и DCOM можно программировать на голом С (во всяком случае, книжку на эту тему я в свое время штудировал - правда, там не было буквы D). Другой вопрос - сколько гемора при этом получается. Но базовый API, вроде, С-шный. Поправьте если вру. А что подумает про меня МС - мне все равно:)

Ладно, я неточно выразился. Правильное слово - не "позволяет", а "провоцирует". И ничего при этом не говорит про скорость. Очень большая разница в производительности выполнения базовых языковых примитивов.

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

Ну, я бы не назвал этот язык попсовым. Правда, точное определение поп-языка дать не берусь. Примерно это звучит так: "Языки, изучив которые на 9-месячных курсах, человек начинает ощущать крутым программистом:)". Но и это неточно. Короче, список будет примерно такой: Basic (во всех его ипостасях), C[(++)#]?, Java, Pascal, Perl, Lisp (даже не Scheme:), PHP, Python. Как-то так. И то - я не уверен насчет Lisp.