Типичные ошибки C++

>приятно поговорить с умным человеком что редкость на ЛОР

Кукушка хвалит петуха за то, что хвалит он кукушку. (Ничего личного - так, навеяло...)

>с++ должен быть таким какой он есть так как, покрайней мере, он динственный носитель иделогии value == object

Глупости. Как я уже заметил есть еще как минимум Ada и Eiffel. К стати в отличие от С++, где "object as value" не полиморфны, в Ada они также полиморфны как и "object as reference".

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

замечу что Вы влезли в не в тему
value == object & object == interface
это совсем не object as/by value, object as/by reference

>1. Язык синтаксически монстроидален (док-во - сравнить размеры стандартов на С и С++)

Согласен.

>2. Перегруженные операторы - зло, ведущее к трудновылавливаемым ошибкам. Особенно операторы присваивания.

Глупости. Мне например, при операциях с матрицами нравится писать 

1) X = A + ( B * ( C - D ) );
а не так
2) X.assign(C.sub(D).mul(B).add(A))

Причем если потребовать неизменности A, B, C и D, то появляются как минимум 3 временных обьекта, что при больших размерах матриц слопает кучу ОЗУ и проц.времени. (С++ "умеет" expression templates, что исключает временные объекты)


>3. Туда же конструкторы копирования.

А вам что такое 

int x = 10;
int y = x;

тоже ненравится?



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

Нельзя.

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

Согласен - не очень хорошо. Однако бывает и хуже - в жаба например можно вызвать виртуальную функцию из конструктора базового класса. Только вот беда - дочерний (ф-ция кот-го выз-ся) класс будет
НЕИНИЦИАЛИЗИРОВАН. 

Можете еще сказать про отсутствие метаклассов.

>5. Попытка в одном языке обеспечить совместимость с С и придать структурам rtti выглядит криво. 

Совместимость с С - это БОЛЬШАЯ ДЫРА В С++. (Хотя это и дает 
преимущество при работе с С-шными либами, это безусловно ЗЛО)

>Кстати, то же по наличие в высокоуровневом языке (smart pointers тосе) такой "хорошей" вещи как void * и char *.

Глупости. Smart-pointer-ами нехошь - непользуйся. void* и char* - это не дыры. Дыра - это IMPLICIT TYPE CONVERSION. 


>Множественное наследование (+виртуальное) делает реюзабельность кода проблематичной. Или надо наследовать все классы виртуально (что дорого) - или заранее знать про все случаи использования данного класса как базового.

Не нравится - непользуйся. (К стати в 99% случаев использование MI - 
дурной тон. MI хорошь в template-ах)

>от спор закрыт начинать новый в попытке прояснить ситуацию уже с Вами ... когда даже не знаю кто Вы, anonymous ... не хочу так что и не уду

Да я и сам нехочу. Вам бы сначала почитать книжки какие нибудь чтоли. Хотя здесь модно незная броду соваться в воду.

а особенно сдесь модно
будучи анонимом, доказывать что ты умнее всех :))))

> Есть "object by value" и "object by reference".

Беседа совсем не об этом была.

> И вообще - невозможность "object by value" - гигантский минус в жаба. Надеюсь догадываетесь почему.

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

> Глупости. Мне например, при операциях с матрицами нравится писать

А мне нет. Потому что при просмотре кода случайно не заметить значок = или * легко. А assign, add, multiply увидишь сразу.

> тоже ненравится?

Не нравится. Вообще мешанина между присвоением и конструированием - еще один "плюс" плюсов.

> Не нравится - непользуйся. Кстати в 99% случаев использование MI - дурной тон

Замечательно. Язык, имеющий важную фичу (влияющую на очень многие вещи) - использование которой в 99% случаев является дурным тоном. Супер-дизайн.;)

> Но ведь a.assign(b) тоже не гарантирует сего для любых a и b.

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

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

Пусть всегда будет С.

> Взялись ведь строить C with classes, а потом понравилось. Т.е. обычная эволюция

Вот так оно и бывает. Увлеклись и на-overengineer-или... При этом запретив себе убить священную корову совместимости с С.

2 yeolahim && svu:
Спасибо за интересный диалог. Было познавательно прочитать. Мысль о object==value, object==interface придумана Вами или была озвучена в таком виде где-нибудь еще? Если была то что можно на эту тему почитать?

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

Для C++ оператор = выглядит подозрительно всегда. Хотя бы потому что для сложного типа он не объявлен приватным :).

> Например, в каком другом _компилируемом_ языке можно записать: > > Mass m = 4; > Acceleration a = 4 ; > Force f = m * a ; // Здесь происходит проверка размерностей во время компиляции! > // И в результирующем коде останется только double = double * double > // То есть _никакого_ overhead

В Common Lisp, вестимо :]

> А Вы, батенька, назовите хотябы один компилятор (кроме Comeau), который бы удовлетворял этим последним стандартам. К стати компиляторы от MS исторически по этому показятелю в заднице. Ситуация начала выправлятся 3 года назад, когда они пригласили на работу Sutter'а, хотя до сих пор даже VC8 по этому показателю отсасывает у gcc.

любые, используеющие фронт-енд edg

>Замечательно. Язык, имеющий важную фичу (влияющую на очень многие вещи) - использование которой в 99% случаев является дурным тоном. Супер-дизайн.;)

Почему-то (может и не в тему) вспомнился Python и lambda, которую грозились выкинуть из языка..