>А ты не понял, что это был ответ за Си++? Тогда ой.

Еще раз: зачем оставлять совместимость с С в 09 году? Кого вы с господином Страусом сейчас от туда переманить хотите?

>Я знаю фанатов такого языка, как Nemerle. В нем чуть ли не все делается метапрограммами. Даже циклы и условные операторы в них -- это вызовы метапрограмм. Надо полагать, что по твоей логике Nemerle говно-говном. Только вот эти самые фанаты Nemerle тебя бы с потрохами съели за такое сравнение. И многие из них понимают в программировании и CS гораздо больше тебя.

Опа, против нас оказывается сборная-дримтим геймдев.ру и РСДН. Бежим!

>По мне, так basic_string -- это обычный шаблонный класс, никакими манипуляциями над программами не занимающийся.

Ну интерпретатор шаблонного кода интерпретирует код basic_string<> подставляя в него параметры чтобы в итоге получить конечный класс. А мне не нужна фабрика по производству семейств стрингов. Мне нужен тупо стринг чтобы тупо вернуть его из функции.

>> 2) Является ли говном тот язык где надо привлекать метапрограмму работающую во время компиляции для того чтобы просто вернуть из функции тупую строчку?

>Я знаю фанатов такого языка, как Nemerle. В нем чуть ли не все делается метапрограммами. Даже циклы и условные операторы в них -- это вызовы метапрограмм.

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

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

Вот так вот легко и изящно было доказано, что С --- говно :)))

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

>Вот так вот легко и изящно было доказано, что С --- говно

Си на ООП и generic programming не претендует в отличие от.

про ежики и кактус - ваша биография ? и менять не намерены ? пока стресс не доконает ? или плюсы не станут ЯВНЫМИ(перевесят залежи мазохизма).

>Си на ООП и generic programming не претендует в отличие от.

Осталось выяснить:

а) как связаны строки, ООП и generic programming

б) как посмели ГыТыКашники тебя ослушаться и делать ООП на С

>а) как связаны строки, ООП и generic programming

Если в языке нет нормальных строк то наличие в нем ООП и generic programming не является той вещью которая заслуживает рассмотрения.

>б) как посмели ГыТыКашники тебя ослушаться и делать ООП на С

Язык и протокол это разные вещи. Питон к примеру - язык, биндинг gtk-реализация протокола. Вполне естественно что реализация ОО-протокола пишется на низкоуровневом языке типа Си.

> Ну интерпретатор шаблонного кода интерпретирует код basic_string<>

(из под стола) пиши еще!

> Мне нужен тупо стринг чтобы тупо вернуть его из функции.

Тупо берешь std::string и тупо возвращаешь, и тупо не заморачиваешься на то, что делает компилятор, а и тупо не 3.14здишь.

> Я так понимаю нормальный стринг в Немерле есть?

Да, нормальный .NET-овский.

>Адепт ООП-религии в понимании С++? Меня не волнует теория - что такое полиморфизм например. Меня волнует как я могу применить полиморфизм чтобы увеличить продуктивность труда по сравнению с Си драматическим образом. Массивы из указателей на функции, так называемые vtable которые обеспечивают полиморфизм в С++ это не более чем синтаксический сахар, который по факту производительность труда не увеличивает. Городить новый язык ради передачи неявного параметра this не стоило.

Absurd * (*) (11.09.2008 13:21:41)

Аналогично можно сказать про ассембер-- городить высокоуровневые языки для того чтобы генерить машинный код не стоило:) Это синтаксический сахар:)

>> требовалось слишком много обвязочного кода для доступа из Ruby/Lua скрипта к данным C++ ядра

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

anonymous (*) (11.09.2008 15:18:31)

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

>> Ну интерпретатор шаблонного кода интерпретирует код basic_string<>

>(из под стола) пиши еще!

А что, в в компиляторе нет интерпретатора шаблонного кода? По стандарту он вроде даже turing-complete. Возможно для этого в С++ есть какой-то свой buzzword, в терминологии не силен.

>> Мне нужен тупо стринг чтобы тупо вернуть его из функции.

>Тупо берешь std::string и тупо возвращаешь, и тупо не заморачиваешься на то, что делает компилятор, а и тупо не 3.14здишь.

Меня какбе интересует минимизация зависимостей в интерфейсах. Мне не нужно чтобы клиент кода должен компилировал половину stl в каждой единице компиляции где вызывается моя функция. К тому же наличие типов вроде

std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >

в отладочных символах лично меня не улыбает. Я конечно понимаю что Строуструп не использует дебагер, как он признался одному слэшдотовцу в приватной беседе. В моем коде я и сам не нуждаюсь в дебагере, так что его позиция понятна. Но на практике в десятки раз чаще приходится в чужом коде разбираться чем писать. А чтобы разобраться неплохо бы его погонять в дебагере. Си-код к примеру можно замечательно и безглючно гонять в дебагере. Хоть в Эклипсе хоть в Емаксе хоть в M$VS, не разу не помню каких-то проблем с этим.

>> Я так понимаю нормальный стринг в Немерле есть?

>Да, нормальный .NET-овский.

Ну вот, потребность в базовых вещах платформа .NET/mono удовлетворяет, можно двигаться дальше.

Re^2: Страуструп о будущем семантических средств разработки с комментариями

> Меня какбе интересует минимизация зависимостей в интерфейсах. Мне не нужно чтобы клиент кода должен компилировал половину stl в каждой единице компиляции где вызывается моя функция. К тому же наличие типов вроде

Да, сложно жить, не осилив pch. Ну да, в твоей любимой visual studio 6.0 его не было.

> в отладочных символах лично меня не улыбает. Я конечно понимаю что Строуструп не использует дебагер, как он признался одному слэшдотовцу в приватной беседе. В моем коде я и сам не нуждаюсь в дебагере, так что его позиция понятна. Но на практике в десятки раз чаще приходится в чужом коде разбираться чем писать. А чтобы разобраться неплохо бы его погонять в дебагере. Си-код к примеру можно замечательно и безглючно гонять в дебагере. Хоть в Эклипсе хоть в Емаксе хоть в M$VS, не разу не помню каких-то проблем с этим.

И почему это у меня c++-код гоняется в дебаггере, а у тебя нет? Может у меня gdb с libastral слинкован?

> И почему это у меня c++-код гоняется в дебаггере, а у тебя нет? Может у меня gdb с libastral слинкован?

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

>Да, сложно жить, не осилив pch. Ну да, в твоей любимой visual studio 6.0 его не было.

AFAIK, даже в VC6.0 было и очень существенно увеличивало скорость компиляции, особенно с использованием MFC.

> Да, сложно жить, не осилив pch. Ну да, в твоей любимой visual studio 6.0 его не было.

6-я студия поддерживает прекомпилированне заголоки, не бзди, а вот gcc 3-ей версии поддерживал pch с ошибками. Приходилось заголовочный файл, которые нужно было скомпилировать, специально обертывать еще одним.

Re^4: Страуструп о будущем семантических средств разработки с комментариями

>> И почему это у меня c++-код гоняется в дебаггере, а у тебя нет? Может у меня gdb с libastral слинкован?

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

Ты не пробовал по жабовским коллекциям в дебаггере лазать? Лично я разницы в сложности восприятия плюсатых и жабных коллекций в дебаггере не наблюдаю.

Re^4: Страуструп о будущем семантических средств разработки с комментариями

>> Да, сложно жить, не осилив pch. Ну да, в твоей любимой visual studio 6.0 его не было.

> 6-я студия поддерживает прекомпилированне заголоки

Тогда непонятно, откуда подобная фобия взялась.

Вот, например. Дальше лень искать. http://mail.python.org/pipermail/c++-sig/2004-January/006608.html

Кстати pch стал поддрживаться в gcc только в 2003 году, вроде.

>> Меня какбе интересует минимизация зависимостей в интерфейсах. Мне не нужно чтобы клиент кода должен компилировал половину stl в каждой единице компиляции где вызывается моя функция. К тому же наличие типов вроде

>Да, сложно жить, не осилив pch. Ну да, в твоей любимой visual studio 6.0 его не было.

Да мне похрен на pch. Просто в описании интерфейсов кода быть не должно ни в каком виде. Ни в виде шаблонов ни в виде шаблонов через #include<>. Только через abi.

>И почему это у меня c++-код гоняется в дебаггере, а у тебя нет? Может у меня gdb с libastral слинкован?

Ну std::string я могу посмотреть, через ж...у правда (str.m_ptr ->...) но могу. Как мне c внутренностями std::map ознакомиться? Да и вообще все С++ тулы глючили и глючить будут, потому что поддерживать в консистентном состоянии фичи С++ и IDE даже MS не под силу.

>>> И почему это у меня c++-код гоняется в дебаггере, а у тебя нет? Может у меня gdb с libastral слинкован?

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

>Ты не пробовал по жабовским коллекциям в дебаггере лазать? Лично я разницы в сложности восприятия плюсатых и жабных коллекций в дебаггере не наблюдаю.

Ложь - в жабе любые объекты реализующие интерфейсы List, Set или Map инспектируются абсолютно кузяво.

>>Да, сложно жить, не осилив pch. Ну да, в твоей любимой visual studio 6.0 его не было.

>AFAIK, даже в VC6.0 было и очень существенно увеличивало скорость компиляции, особенно с использованием MFC.

Да, стандартный вопрос/ответ в любой конфе:

- Что-то у меня какая-то беда с проектом MSVC++

- Отключи pch и прибей ncb

Re^4: Страуструп о будущем семантических средств разработки с комментариями

> Да мне похрен на pch. Просто в описании интерфейсов кода быть не должно ни в каком виде. Ни в виде шаблонов ни в виде шаблонов через #include<>. Только через abi.

Не забывай добавлять к таким высказываниям префикс "В языке моей мечты, коим C++ не является, ..." и люди тебя поймут.

>>И почему это у меня c++-код гоняется в дебаггере, а у тебя нет? Может у меня gdb с libastral слинкован?

> Ну std::string я могу посмотреть, через ж...у правда (str.m_ptr ->...) но могу. Как мне c внутренностями std::map ознакомиться?

А что конкретно не так с мапом?

> Да и вообще все С++ тулы глючили и глючить будут, потому что поддерживать в консистентном состоянии фичи С++ и IDE даже MS не под силу.

Ой, а разве за последний год в grep-е улучшили поддержку C++? :o)

Re^6: Страуструп о будущем семантических средств разработки с комментариями

>>Ты не пробовал по жабовским коллекциям в дебаггере лазать? Лично я разницы в сложности восприятия плюсатых и жабных коллекций в дебаггере не наблюдаю.

> Ложь - в жабе любые объекты реализующие интерфейсы List, Set или Map инспектируются абсолютно кузяво.

Вот именно что "кузяво". Хороший термин подобрал. Пролезть через дебри иерархий, чтобы найти одну -единственную строку, лежащую в 33 элементе массива values подструктуры $%##% -- это верх кузявости.

Re^4: Страуструп о будущем семантических средств разработки с комментариями

>>>Да, сложно жить, не осилив pch. Ну да, в твоей любимой visual studio 6.0 его не было.

>>AFAIK, даже в VC6.0 было и очень существенно увеличивало скорость компиляции, особенно с использованием MFC.

> Да, стандартный вопрос/ответ в любой конфе:
> - Что-то у меня какая-то беда с проектом MSVC++
> - Отключи pch и прибей ncb

То есть я оказался прав и твоя нелюбовь к pch опять же лежит в плоскости твоих сношений с vc6.0? Пора во фрейдисты записываться.

>Не забывай добавлять к таким высказываниям префикс "В языке моей мечты, коим C++ не является, ..." и люди тебя поймут.

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

>>>И почему это у меня c++-код гоняется в дебаггере, а у тебя нет? Может у меня gdb с libastral слинкован?

>> Ну std::string я могу посмотреть, через ж...у правда (str.m_ptr ->...) но могу. Как мне c внутренностями std::map ознакомиться?

>А что конкретно не так с мапом?

Как мне в дебагере вывести содерхимое std::map в виде [key->value, key->value, key->value ...] ?

>> Да и вообще все С++ тулы глючили и глючить будут, потому что поддерживать в консистентном состоянии фичи С++ и IDE даже MS не под силу.

>Ой, а разве за последний год в grep-е улучшили поддержку C++? :o)

И это говорит человек который ненавидит xml в том числе за то что его сложно обрабатывать традиционными юниксовыми утилитами. Ты представляешь себе разницу в сложности парсинга между xml и C++?

>А что, в в компиляторе нет интерпретатора шаблонного кода?

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

>Меня какбе интересует минимизация зависимостей в интерфейсах. Мне не нужно чтобы клиент кода должен компилировал половину stl в каждой единице компиляции где вызывается моя функция.

С 1998-го года STL -- это часть языка. Уже как минимум лет 5 эта часть нормально доступна во всех более-менее вменяемых реализациях C++. Поэтому зависимость от std::string -- это такая же зависимость, как и от char.

>К тому же наличие типов вроде...

Ну понятно. Строготипизированный шаблонный std::sort хуже нетипизированного С-шного qsort-а, потому что имена в отладочной информации очень длинные. Ничего не поделать, такова селяви.

>Строготипизированный шаблонный std::sort хуже нетипизированного С-шного qsort-а, потому что имена в отладочной информации очень длинные

Строгая типизация противоречит концепту UNIX.

>>Строготипизированный шаблонный std::sort хуже нетипизированного С-шного qsort-а, потому что имена в отладочной информации очень длинные

>Строгая типизация противоречит концепту UNIX.

Доказано Абсурдом? Или есть более авторитетные источники?

Кстати, это ничего, что строготипизированный код (особенно проинлайненый, как это обычно происходит с шаблонами), как правило, быстрее?

>Если в языке нет нормальных строк то наличие в нем ООП и generic programming не является той вещью которая заслуживает рассмотрения.

Ой, как мы "изящно" спрыгиваем ))))

Пара вопросов: 1) ты тем самым признаёшь, что сморозил чушь, заявив "если в языке нельзя нормально вернуть стринг из функции, то остальные фичи языка вообще не стоит принимать к рассмотрению"?

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

Или это из всё ещё неопубликованной книги за твоим авторством "С++ и я", куда это войдёт наряду с перлами о "синтаксических нюансах", полиморфизме, инкапсуляции и прочем? Скажи, пожалуйста, когда её ждать на прилавках?

>>>Строготипизированный шаблонный std::sort хуже нетипизированного С-шного qsort-а, потому что имена в отладочной информации очень длинные

>>Строгая типизация противоречит концепту UNIX.

>Доказано Абсурдом? Или есть более авторитетные источники?

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

Есть такая ссылка, месседж думаю понятен http://www.jwz.org/doc/worse-is-better.html

>Кстати, это ничего, что строготипизированный код (особенно проинлайненый, как это обычно происходит с шаблонами), как правило, быстрее?

Кто-то измерял? Больше кода-больше нагрузка на кэш. И это если забыть про бинарную стабильность интерфейсов.

>>>>Строготипизированный шаблонный std::sort хуже нетипизированного С-шного qsort-а, потому что имена в отладочной информации очень длинные

>>>Строгая типизация противоречит концепту UNIX.

>>Доказано Абсурдом? Или есть более авторитетные источники?

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

Т.е., если в Unix-е два процесса обмениваются между собой текстовыми данными, то аналогичным образом нужно поступать и внутри процесса. Здорово!

>Есть такая ссылка, месседж думаю понятен http://www.jwz.org/doc/worse-is-better.html

Тогда нужно давать ссылку на первоисточник: http://www.dreamsongs.com/WorseIsBetter.html -- станет понятно, что Ричард Гебриель возвращался к этой теме несколько раз с разными оценками.

>>Кстати, это ничего, что строготипизированный код (особенно проинлайненый, как это обычно происходит с шаблонами), как правило, быстрее?

>Кто-то измерял?

Если не ошибаюсь, это было опубликовано в книге Герберта Шилдта лет 10 назад.

>Больше кода-больше нагрузка на кэш.

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

>И это если забыть про бинарную стабильность интерфейсов.

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

> Как мне в дебагере вывести содерхимое std::map в виде [key->value, key->value, key->value ...] ?

А дебагер это должен делать? Там же бинарное дерево внутри... Если очень надо, то элементарно дописывается ручками вывод в строку, которая затем и просматривается по наведению мыши.

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

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

Re^6: Страуструп о будущем семантических средств разработки с комментариями

>>Не забывай добавлять к таким высказываниям префикс "В языке моей мечты, коим C++ не является, ..." и люди тебя поймут.

> Прикол в том что производителям компиляторов проще сделать атомарные коллекции чем реализовывать шаблоны, и проще реализовать дегегаты проще чем угребищные C++ указатели на метод.

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

>>> Ну std::string я могу посмотреть, через ж...у правда (str.m_ptr ->...) но могу. Как мне c внутренностями std::map ознакомиться?

>>А что конкретно не так с мапом?

> Как мне в дебагере вывести содерхимое std::map в виде [key->value, key->value, key->value ...] ?

Не знаю. Но в kdevelop-ском отладчике я лазал по мапам так же, как лазаю по java.util.Map-ам в эклипсовом отладчике. Кузяво, конечно, но работает.

>>> Да и вообще все С++ тулы глючили и глючить будут, потому что поддерживать в консистентном состоянии фичи С++ и IDE даже MS не под силу.

>>Ой, а разве за последний год в grep-е улучшили поддержку C++? :o)

> И это говорит человек который ненавидит xml в том числе за то что его сложно обрабатывать традиционными юниксовыми утилитами. Ты представляешь себе разницу в сложности парсинга между xml и C++?

А зачем парсить? Этим пусть компилятор занимается.
Код должен быть читаем и без костылей. И если при написании какого-то куска кода на C++ получается непомерно непонятная поебень, то C++ для него использовать не стоит, ибо это нерационально. (Знаю, что ты сейчас скажешь, что при использовании C++ непомерно непонятная поебень(tm) встречается даже в хелловорлде :о) )

>>Кстати, это ничего, что строготипизированный код (особенно проинлайненый, как это обычно происходит с шаблонами), как правило, быстрее?

>Кто-то измерял?

Например, http://theory.stanford.edu/~amitp/rants/c++-vs-c/

>>>Строгая типизация противоречит концепту UNIX.

... просят пояснить...

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

>Т.е., если в Unix-е два процесса обмениваются между собой текстовыми данными, то аналогичным образом нужно поступать и внутри процесса. Здорово!

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

>>>Кстати, это ничего, что строготипизированный код (особенно проинлайненый, как это обычно происходит с шаблонами), как правило, быстрее?

>>Кто-то измерял?

>Если не ошибаюсь, это было опубликовано в книге Герберта Шилдта лет 10 назад.

Субъективно программы написанные в hardcore С++ стиле экстраоординарным перформансом не блешут. KRON недавно замерял производительность iostream vs stdio - она у iostream хуже.

>>И это если забыть про бинарную стабильность интерфейсов.

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

Ну и в топку.

>>Т.е., если в Unix-е два процесса обмениваются между собой текстовыми данными, то аналогичным образом нужно поступать и внутри процесса. Здорово!

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

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

Во-вторых, хотелось бы примеров различных версий этих протколов.

В-третьих, хотелось бы понять, что разумного в том, что qsort можно подсунуть указатель на float* и функцию сравнения двух int-ов.

>Субъективно программы написанные в hardcore С++ стиле экстраоординарным перформансом не блешут. KRON недавно замерял производительность iostream vs stdio - она у iostream хуже.

Это ничего, что сравнение iostream vs stdio -- это сравнение мелкого с мягким?

>> И это говорит человек который ненавидит xml в том числе за то что его сложно обрабатывать традиционными юниксовыми утилитами. Ты представляешь себе разницу в сложности парсинга между xml и C++?

>А зачем парсить? Этим пусть компилятор занимается.

В предыдущей мессаге был предложен grep для парсинга C++ кода

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

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

Протокол - это набор виртуальных функций предоставляемых библиотекой. Клиент - это тот которого надо перекомпилировать при добавлении виртуальных функций.

>Во-вторых, хотелось бы примеров различных версий этих протколов.

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

>В-третьих, хотелось бы понять, что разумного в том, что qsort можно подсунуть указатель на float* и функцию сравнения двух int-ов.

Такой проблемы не существует.

Re^8: Страуструп о будущем семантических средств разработки с комментариями

>>> И это говорит человек который ненавидит xml в том числе за то что его сложно обрабатывать традиционными юниксовыми утилитами. Ты представляешь себе разницу в сложности парсинга между xml и C++?

>>А зачем парсить? Этим пусть компилятор занимается.

> В предыдущей мессаге был предложен grep для парсинга C++ кода

О_о! для работы с текстом программы, а не для парсинга кода.

>>В-третьих, хотелось бы понять, что разумного в том, что qsort можно подсунуть указатель на float* и функцию сравнения двух int-ов.

>Такой проблемы не существует.

Вопрос закрыт.

Можешь пинать C++ сколько угодно, а еще лучше -- перейди полностью на Java или C#. Они как раз для таких как ты создавались.

>>>Кстати, это ничего, что строготипизированный код (особенно проинлайненый, как это обычно происходит с шаблонами), как правило, быстрее?

>>Кто-то измерял?

>Например, http://theory.stanford.edu/~amitp/rants/c++-vs-c/

Если ему надо так часто сортировать, почему бы не поддерживать коллекцию в отсортированном виде изначально, отыскивая посадочное место для очередного элемента с помощью бинарного поиска. Оно O(log(N)), то есть для массива длиной 65535 элементов функция сравнения будет вызвана 16 раз.

>>>В-третьих, хотелось бы понять, что разумного в том, что qsort можно подсунуть указатель на float* и функцию сравнения двух int-ов.

>>Такой проблемы не существует.

>Вопрос закрыт.

Проблемы "забывания" действительно в С++ не существует. Она есть в Си, в Си++ на фоне остальных проблем ее не видно.

>Можешь пинать C++ сколько угодно, а еще лучше -- перейди полностью на Java или C#. Они как раз для таких как ты создавались.

Для каких создавалась Java или C#?

>И если при написании какого-то куска кода на C++ получается непомерно непонятная поебень, то C++ для него использовать не стоит, ибо это нерационально.

По-моему мы докопались до сути: подозреваю, у Абсурда при написании ЛЮБОГО куска кода на С++ получается "непомерно непонятная поебень", отсюда и проблемы. Плюс непоправимый урон, нанесённый Вижуал Сиплюсплюсом 6.0 + boost в раннем детстве....

>> Как мне в дебагере вывести содерхимое std::map в виде [key->value, key->value, key->value ...] ?

>А дебагер это должен делать? Там же бинарное дерево внутри... Если очень надо, то элементарно дописывается ручками вывод в строку, которая затем и просматривается по наведению мыши.

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

> Еще раз: зачем оставлять совместимость с С в 09 году?

Это совместимость с Си++.

> Кого вы с господином Страусом сейчас от туда переманить хотите?

Тебе что-то мерещится.

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

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

Плюсы дают максимум производительности и при всем при этом там много всего интересного можно придумать.

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

А если проекты интересные, а язык при этом - вялотекущий унылый маразм, который добививает отсутствием элементарных вещей?

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

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

> Я знаю фанатов такого языка, как Nemerle.

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

Ну ты и задрот!