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

Хинт: Matrix F = A+B+C+D+E; *может* вычисляться в момент присваивания и так, чтобы эффективно использовать доступ проца к памяти. Если после этого все-таки хочется ссылку -- будет.

Но мне хотелось бы обсуждать (и находить) именно недостатки плюсов, а не твои недостатки. Почему и тебе предлагаю отточить свои аргументы против плюсов и собрать их в одно место.

>Плюсовики не способны воспринимать доводы. Ты что сам этого еще не заметил?

Если ты правда так считаешь, то твоя деятельность тут бесполезна.

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

Может все же займешься отжатым списком недостатков?

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

Или вот: Derived* -> void* -> Base* (кстати, моя реализация наследования НЕ рушиться на этой не-стандартной цепочке)

Опять повторю -- местами твоя критика плюсов очень интересна. Хотелосы бы в ней видеть больший процент действительно проблем плюсов.

> У меня нет такой пылающей красноглазой ненависти к плюсам, что-бы вести подобные исследования. Просто высказываю свое мнение.

У меня тоже нет... но такое исследование мне интересно, а так же будет полезно. Мнение не основанное на (хотя бы маленьком личном) исследовании мне мало интересно.

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

>Хинт: Matrix F = A+B+C+D+E; *может* вычисляться в момент присваивания и так, чтобы эффективно использовать доступ проца к памяти.

Ну если матрица имеет фиксированный размер скажем 4x4 и имеет конструктор с 16 параметрами - Matrix(el11, el12, el13....), то возврат по значению в operator+() можно наверно оптимизировать типо так:

Matrix operator+(const Matrix& lho, const Matrix& rho) { return Matrix(lho[1][1] + rho[1][1], lho[1][2] + rho[1][2], ...) }

Возможно Intel C++ даже сгенерит тут приемлемый код.

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

>>(Абсурд в минимум половине случаев просто плюсов не знает)

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

Тут нет эскалации, так как бисер (т.е. интересное) ты иногда выдаешь, и не все свиньи, так как хотя бы я это (для себя) замечаю. Впрочем, развивать этот бисер в направлении "убить с++" мне не интересно.

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

Можно вопрос?

#define public private в C++ классы уже не ломает?

> Я вижу ты полностью проигнорировал мой пост во всем остальном, кроме целочисленых типов.

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

Давай лучше вместе поищем недостатки плюсов.

> #define public private в C++ классы уже не ломает?

Ломает. Но случайно такое не делается. А вот слабо вспомнить естественный код, который компилятор молча съест, и который при этом будет полностью ошибочен?

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

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

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

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

А вот это - очень грамотная позиция. Хотя если её логически продолжить, то лучше с самого начала воспользоваться другими языками (или их связкой), но не C++. Потому что в больших проектах довольно сложно будет предсказать момент появления непомерно непонятной поебени, а менять что-то бывает уже слишком поздно. В таком случае лучше попытаться изначально свести риск к минимуму, т.к. C++ изначально больше располагает к появлению непомерно непонятной поебени.

>CPP позволяет писать программы в самых разных стилях, и это его плюс.

>Вообще, писать программы только в одном стиле - полнейшая глупость. Даже обсуждать смешно.

Есть известная байка про Сталина. Сталин захотел, чтобы конструкторы сделали новый танк, который ездит по суше, плавает по воде, летает и погружается под воду. Конструкторы услышали это и поникли, никто не осмелится сказать: "Ты чо совсем дятел? Хуйню какую-то гонишь!" Затем встал один из конструкторов и сказал что-то вроде: "В природе есть птица, которая всё это умеет, это утка. Но каждую из вещей она делает ТАК ПЛОХО!" Сталин всё понял и своё желание отменил.

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

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

О боже, это лев! Бежим в машину!

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

> Это позиция страуса (Страуса?) - прятать голову в песок и делать вид, что проблемы не существует. Производителям компиляторов тяжело, поэтому в компиляторе могут появляться ошибки. Эти ошибки рано или поздно будут причудливым образом проявляться и мешать вам.

> Всё-таки лучше быть уверенным в надёжности инструмента, а не сомневаться - "это я дурак, или компилятор глючит?"

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

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

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

Выбирай язык под задачу и проблем не будет. Нужна гибкость и расширяемость -- не бери сиплюсплюс. Нужны алгоритмы со сложными структурами и (математическими) объектами -- бери сиплюсплюс.

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

А вот это уже головотяпство. В современном ынтырпрайз-софтописании сиплюсплюс действительно будет порождать ННП. Но ынтырпрайз-фостописание -- это не все области программирования.

>Вот тут РСДНовец плакался, что быдлокодеров-крестовиков можно толпу нанять за еду, а с другими языками вроде ОКамла этот фокус не пройдет.

Точную ссылку на этот плач в студию.

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

http://www.linux.org.ru/view-message.jsp?msgid=2804957&page=15#2810231

> Проблема в том, что многие люди сильно любящие C++ этого не понимают, они всю жизнь ели суррогат, и думают что это и есть настоящее.

А что не суррогат?

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

>http://www.linux.org.ru/view-message.jsp?msgid=2804957&page=15#2810231

Лишнее доказательство что плюсофилы - невменяемые догматики. Хотя можно спросить, как Вы относитесь к наследованию в стиле COM: производный класс делегирует IUnknown->QueryInterface() наверх по иерархии или полиморфизму в стиле Objective C? Давайте предположим что это и есть настоящее наследование и настоящий полиморфизм.

>Хотя можно спросить, как Вы относитесь к наследованию в стиле COM: производный класс делегирует IUnknown->QueryInterface() наверх по иерархии

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

Так что извращения в стиле COM номальным наследованием я не считаю.

>>Хотя можно спросить, как Вы относитесь к наследованию в стиле COM: производный класс делегирует IUnknown->QueryInterface() наверх по иерархии

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

Ничто не мешает делать компиляторы нативного кода под эти OO-протоколы. Дельфи 2 my mind так и делал. Под GTK+ возможно Vala это будет делать.

>Так что извращения в стиле COM номальным наследованием я не считаю.

Ну то что реализацию нормального OO на С++ дяже плюсофилы считают извращением - это показательно.

>Ничто не мешает делать компиляторы нативного кода под эти OO-протоколы. Дельфи 2 my mind так и делал. Под GTK+ возможно Vala это будет делать.

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

>>Так что извращения в стиле COM номальным наследованием я не считаю.

>Ну то что реализацию нормального OO на С++ дяже плюсофилы считают извращением - это показательно.

Доказано Абсурдом или есть вменяемые ссылки в доказательство этого тезиса.

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

>>Ничто не мешает делать компиляторы нативного кода под эти OO-протоколы. Дельфи 2 my mind так и делал. Под GTK+ возможно Vala это будет делать.

>Охринительно успешные языки...

Про то сколько кода написано для архитектуры COM и сколько на нем зарабатывается пускай gggg какой-нибудь поорет.

>>>Так что извращения в стиле COM номальным наследованием я не считаю.

>>Ну то что реализацию нормального OO на С++ дяже плюсофилы считают извращением - это показательно.

>Доказано Абсурдом или есть вменяемые ссылки в доказательство этого тезиса.

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

>>>Ну то что реализацию нормального OO на С++ дяже плюсофилы считают извращением - это показательно.

>>Доказано Абсурдом или есть вменяемые ссылки в доказательство этого тезиса.

>Зачем тебе ссылки? Безоговорочно доверяешь авторитетам? Поэтому ты и плюсофил.

Затем, что утвержение о том, что "реализацию нормального OO на С++ дяже плюсофилы считают извращением" противоричит окружающей меня действительности, данной мне в ощущениях.

Хочется увидеть живое доказательство данного утверждения.

btw: Страуструп и, например, Бертран Мейер или Гради Буч считаются авторитетами, потому что они объясняют свои технические решения и предпочтения. В отличии от Absurd, Sidrian и morbo.

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

Простите, а где Вы в крестах хотя бы сурогат ФП нашли? о_О

>>>Ничто не мешает делать компиляторы нативного кода под эти OO-протоколы. Дельфи 2 my mind так и делал. Под GTK+ возможно Vala это будет делать.

>>Охринительно успешные языки...

>Про то сколько кода написано для архитектуры COM

Ну расскажи, сколько кода написано для архитектуры COM вне Windows.

> Простите, а где Вы в крестах хотя бы сурогат ФП нашли? о_О

Compile-time вычисления на основе шаблонов.

Почему я не удивлен, что C++ поносит человек, не знающий языка?

>Страуструп и, например, Бертран Мейер или Гради Буч считаются авторитетами, потому что они объясняют свои технические решения и предпочтения. В отличии от Absurd, Sidrian и morbo.

Ага, а "предатели родины" вроде Александреску как только заявляют, что кресты гавно и пора валить на новые более прогрессивные языки сразу авторитетами для плюсофилов быть перестают ;)

>Compile-time вычисления на основе шаблонов.

о_О

>Почему я не удивлен, что C++ поносит человек, не знающий языка?

Почему я не удивлен, что С++ любят люди не представляющие что такое ФП?

> Почему я не удивлен, что С++ любят люди не представляющие что такое ФП?

Много ли кода на ФП ты написал и запустил в эксплуатацию?

> Ага, а "предатели родины" вроде Александреску как только заявляют, что кресты гавно и пора валить на новые более прогрессивные языки сразу авторитетами для плюсофилов быть перестают ;)

Пруфлинка, полагаю, ждать бесполезно.

>Точную ссылку на этот плач в студию.

http://www.linux.org.ru/view-message.jsp?msgid=3076729&page=12#3083440

>Видите ли, понятия "чаще" или "реже" становятся совершенно бесполезными когда нужно решить конкретную задачу, на конкретном железе, с конкретными требованиями по производительности. И тут оказывается, что на C++ ее можно решить в текущих условиях. А вот на Java+Python или Eiffel, или Ada -- нет. Причем главным препятствием для этих языков будут вовсе не их языковые свойства, а наличие/стоимость инструментов, подготовленных разработчиков и прочей инфраструктуры.

>Много ли кода на ФП ты написал и запустил в эксплуатацию?

Сынок давай повесели нас еще. Ты BLL за ФП в крестах принял чтоли?

>> Ага, а "предатели родины" вроде Александреску как только заявляют, что кресты гавно и пора валить на новые более прогрессивные языки сразу авторитетами для плюсофилов быть перестают ;)

>Пруфлинка, полагаю, ждать бесполезно.

В плюсосраче Изи Крейнина на с++.moderated Александреску заявил что "Я устал доказывать что GC-это краеугольный камень статической безопасности типов, но местная публика исключительно твердолоба. Я сомневаюсь, что Вам это удастся"

>Видите ли, понятия "чаще" или "реже" становятся совершенно бесполезными когда нужно решить конкретную задачу, на конкретном железе, с конкретными требованиями по производительности. И тут оказывается, что на C++ ее можно решить в текущих условиях. А вот на Java+Python или Eiffel, или Ada -- нет. Причем главным препятствием для этих языков будут вовсе не их языковые свойства, а наличие/стоимость инструментов, подготовленных разработчиков и прочей инфраструктуры.

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

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

Диагноз: дислексия. Метод лечения: госпитализация в биореактор. Следующий!

>>Пруфлинка, полагаю, ждать бесполезно.

>В плюсосраче Изи Крейнина на с++.moderated Александреску заявил что "Я устал доказывать что GC-это краеугольный камень статической безопасности типов, но местная публика исключительно твердолоба. Я сомневаюсь, что Вам это удастся"

И? Где Александреску сказал, что C++ говно?

btw: в таком языке, как Ada, GC был добавлен в стандарт только в Ada2005. И, насколько я знаю, GC в Ada поддерживается только в версиях для .NET/JVM. А уж Ada крайне сложно обвинить в отсутствии статической безопасности типов.

http://www.developers.org.ua/salary-db/data/salary-by-year/2008/

По цене крестовики между похапешнегами и точкаНЕТчиками...

> Диагноз: дислексия. Метод лечения: госпитализация в биореактор. Следующий!

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

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

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

>"реализацию нормального OO на С++ дяже плюсофилы считают извращением" противоричит окружающей меня действительности, данной мне в ощущениях.

Окружающая действительность в том что приложение написанное на "ОО" из С++ - вещь в себе. А если оно поддерживает инфраструктуру COM то оно элементарно интегрируется с другими приложениями.

>Страуструп и, например, Бертран Мейер или Гради Буч считаются авторитетами, потому что они объясняют свои технические решения и предпочтения.

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

>Может все таки продолжишь доставлять лулзы о ФП в крестах?

ФП в шаблонах C++ применяли и будут применять.

А вот ты о своем опыте использования ФП в работе почему-то стесняешься сказать. Все так печально?

>http://www.developers.org.ua/salary-db/data/salary-by-year/2008/

>По цене крестовики между похапешнегами и точкаНЕТчиками...

Средняя зарплата С++ника в $1200. Бу-га-га. Вот уж действительно, нищая Украина.

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

>>>Пруфлинка, полагаю, ждать бесполезно.

>>В плюсосраче Изи Крейнина на с++.moderated Александреску заявил что "Я устал доказывать что GC-это краеугольный камень статической безопасности типов, но местная публика исключительно твердолоба. Я сомневаюсь, что Вам это удастся"

>И? Где Александреску сказал, что C++ говно?

В книжке "Modern C++ Design" он это сказал, только иносказательно.

>Средняя зарплата С++ника в $1200. Бу-га-га. Вот уж действительно, нищая Украина.

Тоесть в дефолтсити крестовики получают больше жабакодеров, я тебя правельно понял?

>>"реализацию нормального OO на С++ дяже плюсофилы считают извращением" противоричит окружающей меня действительности, данной мне в ощущениях.

>Окружающая действительность в том что приложение написанное на "ОО" из С++ - вещь в себе. А если оно поддерживает инфраструктуру COM то оно элементарно интегрируется с другими приложениями.

Т.е. то, что плюсофилы считают извращением то, что существует в C++ -- это, все таки, твой личный опыт?

А твоему личному опыту не противоречит то, что:

приложение написанное на "ОО" из Java - вещь в себе.

приложение написанное на "ОО" из Eiffel - вещь в себе.

приложение написанное на "ОО" из SmallTalk - вещь в себе.

???

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

Ты, видимо, не читал "Дизайн и эволюцию языка C++".

Сокращенный перечень можно найти даже в книге "Язык программирования C++", раздел 1.6.1 "Рекомендации для программистов на C" (в 3-ем издании).

>>Средняя зарплата С++ника в $1200. Бу-га-га. Вот уж действительно, нищая Украина.

>Тоесть в дефолтсити крестовики получают больше жабакодеров, я тебя правельно понял?

Это твою галлюцинации.

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

Я увидел поддержку "суррогата ФП", что и было сказано в http://www.linux.org.ru/jump-message.jsp?msgid=3076729&cid=3092723

А примеры использования этого суррогата вот:

http://www.rsdn.ru/forum/?mid=1453312

http://www.rsdn.ru/forum/?mid=1453312

http://ubiety.uwaterloo.ca/~tveldhui/papers/Template-Metaprograms/meta-art.html

Попробуй доказать, что это императивное программирование.

>Первый пример пусть будет демонстрировать как мне вернуть апвард фунарг.

Не раньше, чем ты откроешь страшную тайну о своем опыте использования ФП. А то у меня складывается впечатление, что тебя здесь учат забесплатно.

ОК, понятно, Ц ялвяется ОО языком, мотому что гномеры пишут на нем в ОО стиле. Слив засчитан.

>>Окружающая действительность в том что приложение написанное на "ОО" из С++ - вещь в себе. А если оно поддерживает инфраструктуру COM то оно элементарно интегрируется с другими приложениями.

>А твоему личному опыту не противоречит то, что приложение написанное на "ОО" из Java - вещь в себе.

Нет, жабский код интегрируется замечательно.

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

>Ты, видимо, не читал "Дизайн и эволюцию языка C++".

Читал. Самое главное то что у него хватило времени на то чтобы и узреть негодность Симулы для его задачи и вовремя написать рабочий код на ассемблере BCPL, не завалив при этом диссертацию. Но почему-то он пришел к странному выводу что на Симуле код был красивее и надо из Си сделать Симулу, что неправильно поскольку Симула просто отняла у него время.