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

>А линуксоиды и бсдшники - предпочитают наступать на грабли, которым более 30 лет? Все на форточки, товарищи! :-(

А может таки совсем наоборот 8)

> А может таки совсем наоборот 8)

WinAPI меньше лет, чем POSIX. "Так шта"... (С) Или надо признать, что старые идеи могут быть лучше новых или переходить на оффтопик. =)

>Где я это сказал??? Я утверждаю, что С++ - гадость. Но никогда не говорил, что все плюсовые проекты никуда не годятся. Цитируйте, пожалуйста, точнее.

Ну а аргументами Вы свое утверждение подкреплять собираетесь или как?

Только вменяемыми, пожалуйста, не нужно следовать глупым традициям данного сайта "ХХХ --- тру, УУУ --- ацтой!! Патамушта тру!! Патамушта ацтой!!!"

Подчёркивание в ключевых словах:
например, такие варианты:
__cdecl, _cdecl, __inline и т.д.

конструкция вида
virtual void OnDraw(CDC* pDC) = 0;
просто уродство

MFC - всегда был уродством.

"Выбирая язык, ты выбираешь судьбу. И чтобы эта судьба не зависила от воли левой пятки Microsoft или Borland, необходимо писать так, чтобы программа транслировалась любым независимым компилятором." (C) Крис Касперски ака мыщьх

Беда в том, что это не только в MFC:
http://www.ufalug.rb.ru/docs/gcc1/gcc1-2.html
цитата оттуда:

"Эта опция выключает некоторые свойства GNU CC, которые несовместимы с ANSI C такие, как ключевые слова asm, inline и typeof, предопределенные макросы такие, как unix и vax, которые идентифицируют тип используемой вами системы. Она также включает нежелательные и редко используемые ANSI трехсимвольные последовательности, не разрешает '$' в идентификаторах и комментарии в стиле C++ '//'.

Альтернативные ключевые слова __asm__, __extension__, __inline__ и __typeof__ продолжают работать не смотря на '-ansi'. Вы, разумеется, не хотели бы использовать их в ANSI C программе, но полезно использовать их в заголовочных файлах, которые могут быть включены в компиляции с '-ansi'."

согласен

Ой, мы уж столько раз ругались на эту тему... Вкратце:

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

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

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

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

5. Попытка в одном языке обеспечить совместимость с С и придать структурам rtti выглядит криво. Кстати, то же по наличие в высокоуровневом языке (smart pointers тосе) такой "хорошей" вещи как void * и char *.

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

99. (уже высказано выше) Хороший код на С++ бывает. И он действительно красив и понятен и удобен (и даже, пожалуй, немного более читаем, чем хороший код на С). Но хороших пейсателей на С++ не очень много (впрочем, это про любой язык). А код плохих пейсателей мейнтейнить СИЛЬНО сложнее, чем плохих пейсателей на С. Почему? См все пункты выше.

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

Мнение: с++ - язык, который позволяет удобно выражать мысли профессионалам (китайские программисты на нём программировать не способны), Java - язык для дешевой разработки кода китайскими программистами (написать на нём неподдерживаемый код непрофессионалу значительно сложнее), Си - язык системных хакеров.

PS: ничего против китайцев не имею (и частенько у них лучше код, чем у наших) :).

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

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

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

Несмотря на то, что понятие "хороший писатель", несколько субъективное, но в принципе согласен.

> А код плохих пейсателей мейнтейнить СИЛЬНО сложнее, чем плохих пейсателей на С. Почему? См все пункты выше.

Ага. Во всём виноваты плохие писатели. Поэтому и язык плохой. :)

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

Блин, ну при чем тут национальность?..

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

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

Я же говорю, первое что пришло в голову. Еще из того чем я пользуюсь - DjVu viewer прекрасно работает, нет претензий по качеству. Inkscape - общепризнанно векторный редактор мирового уровня, им и на маках дизайнеры пользуются. Про инкскейп, как думаешь, сколько лет его бы на С писали люди? Это из того чем я пользуюсь. Конечно на C++ проектов меньше чем на С о чем речь. Но знаешь, что-то не могу вспомнить ни одного хренового C++ приложения. Если конечно мы не будем рассматривать всякие поделки, коих и на C сонмище понаписали дилетанты.

>> Так что не нужно обобщать, что все проекты на C++ гамно
> Где я это сказал??? Я утверждаю, что С++ - гадость.

Я тебя не так понял значит. Или ты мысль не очень ясно выразил. А чем C++ гадость-то хотелось бы послушать, если тебе не трудно. Кратко хотя бы. Основные тезисы.

> Цитируйте, пожалуйста, точнее.
No probs! Давай лучше на "ты", если не возражаешь. Не люблю весь этот англо-американский официоз, мне нравится как в Испании и Латинской Америке, когда на "ты". Как-то это более человечно. Не сочти за фамильярность, тебя я очень уважаю как разработчика Свободного ПО, да и просто приличного и умного человека, не "совка", как многие здесь; это видно по твоим постам. Хотя мне и не очень нравится направление развития вашего детища. Но я за многообразие, лишь бы свободное было.

>> URL на описание GNOME hints,
> Энто хто такое? За время жизни гнома этим словом назывались разные вещи;)
> http://www.gtk.org/api/3.6/gtk/GtkTooltips.html

Не, не это. Это как EWMH (Extended Window Manager Hints), только ваши специфичные GNOMEвские расширения. Я FVWM занимаюсь в свободное время, мне бы этот документ не помешал. А GTK, что теперь уже не GIMP Toolkit, а GNOME Toolkit, часть GNOME уже да?

GNOME COMPLIANCE
Fvwm attempts to be GNOME (version 1) compliant. Check http://www.gnome.org for
what that may mean. To disable GNOME hints for some or all windows, the
GNOMEIgnoreHints style can be used.

Вот это мне и надо. Заранее благодарен.

> Про инкскейп, как думаешь, сколько лет его бы на С писали люди?

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

> Кратко хотя бы. Основные тезисы.

Выше приведены;)

> Давай лучше на "ты", если не возражаешь. Не люблю весь этот англо-американский официоз

Можно попробовать. Только англо-американскость не при чем - обращение на "Вы" по умолчанию к малознакомому(незнакомому) человеку давно было нормой русского языка, не так ли?

По поводу хинтов - вопрос понял. Я не уверен, что у гнома есть свои (впервые об этом слышу). Всю дорогу казалось, что гном просто стандартизовал через fd.o и EWMH все, что ему нужно было;)

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

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

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

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

Ну это, извините, руки.... Как грится, "не уверен --- не обгоняй"....

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

Конструктор базового класса и не должен ничего знать о своих дочерних классах. С какой стати? Он знает о себе и о том, кого наследует. В момент создания базового класса нет _никакой_ информации о том, будет ли его вообще кто-то наследовать.

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

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

>Чего-то еще вроде было, но это первое, что вспоминается (и основное, пожалуй). Сидеть на двух стульях - почти-ассемблерного С и высокоуровневого ООП - может, иногда и прикольно, но раскорячно.

Все в руках программиста. Я не использую С-шные фичи в своем коде, не пользуюсь void* и почти не пользуюсь char* (кроме тех случаев, когда этого требуют какие-то C-шные библиотечные функции). Мне вполне хватает одного стула =)

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

Ошибки проектирования --- это нечто другое, не правда ли? =)

Я очень советую Вам посмотреть на библиотеки boost.org, особенно на Spirit, Phoenix2.
Они активно используют перегрузку. Я думаю Вы измените свое отношение в перегрузке операторов.

Так же уделите внимание MPL (Meta Programming Library). Там есть раздел посвященный арифметике с контролем размерности величин
(http://boost.org/libs/mpl/doc/tutorial/dimensional-analysis.html). Например, в каком другом _компилируемом_ языке можно записать:

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

Force f1 = m ; // эта строчка даже не откомпилируется

В стандарте C++ заложен большой потенциал и сейчас начинают появлятся библиотеки которы показывают истинную мощь C++.

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

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

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

точное высказывание - сравните размер грамматик (если вы сравниваете синтаксис)
да С++ больше, но он меньше чем другие ... где критерий ?

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

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

суть что перегрузка операторов это возможность а не необходимость
и эта возможность была введена как логичное продолжение введения ООП как ATD
еще раз С++ и С - это один и тот-же язык в базовых принципах:
"если что то есть - то оно существует в полной мере без каких либо ограничений"

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

еще раз ООП в принципе невозможен без правил копирования объектов
если исходить из принципов С - value == object
то у вас есть только один путь - конструкторы копирования

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

во первых вы пытаетесь в данном утверждении разрушить С (не в С++),
в С !! (не в С++) нет динамики, value == object
нет возможности заглянуть вперед

это вообще невозможно В UNIX !!!!!! (в добавок вы пытаетесь разрушить архитектуру системы)

будте осторожны в критике простых базовых вещей - это может разрушить архитектуру всей системы

5. Попытка в одном языке обеспечить совместимость с С и придать структурам rtti выглядит криво. Кстати, то же по наличие в высокоуровневом языке (smart pointers тосе) такой "хорошей" вещи как void * и char *.

c++ - это первая попытка расширить UNIX
не неудачная, а демонстрирущая не развитость UNIX
а void * и char * - это только типы данных
тут есть очень много поводов для споров, но давайте сойдемся на том
что это просто типы данных

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

еще раз - множественное наследование это возможность а не необходимость
введено было только по одной причине -
value == object
value1 == value2 == value3 - возможная конструкция (и верная)
пример char, short, long

>> 99. (уже высказано выше) Хороший код на С++ бывает. И он действительно красив и понятен и удобен (и даже, пожалуй, немного более читаем, чем хороший код на С). Но хороших пейсателей на С++ не очень много (впрочем, это про любой язык). А код плохих пейсателей мейнтейнить СИЛЬНО сложнее, чем плохих пейсателей на С. Почему? См все пункты выше.

плохой с код - хуже чем плохой С++ код
но безграмотный код - вне конкуренции на любом языке

>> Чего-то еще вроде было, но это первое, что вспоминается (и основное, пожалуй). Сидеть на двух стульях - почти-ассемблерного С и высокоуровневого ООП - может, иногда и прикольно, но раскорячно.

c++ не сидит на двух стульях - он логичное продолжение C
раскорячно сидеть на стуле С и на стуле некого другоко языка никак не являющегося с++, но предпологаемого Вами в его роли

у c++ есть только одна проблема
пытаясь расширить модель исполнения в UNIX - он оставил UNIX как есть

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

Есть у меня подозрения, что можно было проще (доказать не возьмусь). Да, и objective С вроде не столь монстроидален (впрочем, я его смотрел одним глазом).

> Ну это, извините, руки.... Как грится, "не уверен --- не обгоняй"....

Дык я за то и ругаю плюсы - именно за high requirements к рукам и возможность понаделать делов при наличии недостаточно прямых рук.

> А если виртуальный метод дочернего класса обращается к своим приватным данным? Вы считаете, что из базового класса должна быть возможность оперировать с ними? Вы уверены, что хорошо понимаете принципы ООП?

Дело не в ООП как таковом, а в объектной модели. См. следующую мессагу.

> Все в руках программиста. Я не использую С-шные фичи в своем коде, не пользуюсь void* и почти не пользуюсь char*

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

> Ошибки проектирования --- это нечто другое, не правда ли? =)

Один из базовых selling points плюсов - реюзабельность кода. Как же код может быть реюзабельным, если применимость иерархии классов в общем случае ограничена тем проектом, на который она изначально рассчитывалась?;)

Про виртуальность и конструкторы.
Скомпилите пожалста и запустите жабский код:

public class a {
public void callme(String param) {
System.out.println("b.callme: " + param);
}

public a(String param) {
this.callme(param);
}

public static void main(String args[]) {
a theA = new b("taram");
}
};

class b extends a {
public b(String param) {
super(param);
}

public void callme(String param) {
System.out.println("b.callme: " + param);
}
}

% javac a.java
% java a
b.callme: taram

Просто в жабе сначала стоится в памяти ВЕСЬ объект (до конца), а потом вызываются конструкторы.

> Они активно используют перегрузку. Я думаю Вы измените свое отношение в перегрузке операторов.

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

Распространенное (ну, на тот момент, когда я плюсовал) развлечение новичков - obuse перегрузки. Начинают перегружать что попало и как попало. И огребают.

> истинную мощь C++

Вот-вот. С++ - это полтонны урана. Умелец (каких мало) построит хорошую бомбу или безопасную АЭС. А головотяп (каких большинство) - Чернобыль.

> Компилятор языка D так и поступает. А все классы там наследуются виртуально.

Логичное решение. Мысленно записал плюсик языку D. Но плюсы-то от этого лучше не становятся?;) Им мешает бинарная совместимость с сями...

> где критерий ?

Критерий - простота (в данном случае). Для понимания и изучения.

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

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

> во первых вы пытаетесь в данном утверждении разрушить С

Да! Именно! С никогда не задумывался как ОО язык! И идея тащить совместимость была сомнительной ИМХО.

> это вообще невозможно В UNIX !!!!!!

См. выше жабский пример. Работает в унихе, винюках и где угодно.

> что это просто типы данных

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

> еще раз - множественное наследование это возможность а не необходимость

Если язык вводит фичу, он отвечает за то, чтобы ее использование не противоречило другим фичам языка. Как указано выше, реализация наследования в плюсах ставит вопрос над реюзабельностью кода (справедливости ради, словечки final и private в жабке тоже не очень полезны в этом смысле).

> плохой с код - хуже чем плохой С++ код

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

> раскорячно сидеть на стуле С и на стуле некого другоко языка никак не являющегося с++, но предпологаемого Вами в его роли

Да вообще надо было оставить табуретку С в покое, если взялись строить ОО язык. А байндинги к сишным библиотекам построить всегда можно, как показывает опыт мульона других языков (ОО и не очень).

думаю что откажусь от спора

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

для меня с++ - это просто язык
логичный, обладающий цельностью

кстати:
>> это вообще невозможно В UNIX !!!!!!
> См. выше жабский пример. Работает в унихе, винюках и где угодно.

в добавок ко всему Java это платформа ...
ваш код работает на этой платформе !
в добавок там ошибка :)
в третих - это потенциально опасная игра :)

хотел бы я иметь платформу подобную java
но такую-же минималистичную как Unix :)))

>>>
Да вообще надо было оставить табуретку С в покое, если взялись строить ОО язык.

согласен :)))
только одна проблема
никто не знает как слезть с этой табуретки
Java не сидит на ней только по одной причине - это стол
с табуреткой спрятанной под ним ....

> в добавок там ошибка :)

??? Скомпилил и заработало. Где ошипка?;)

> хотел бы я иметь платформу подобную java но такую-же минималистичную как Unix :)))

Смотря в чем подобную...

> Java не сидит на ней только по одной причине - это стол с табуреткой спрятанной под ним ....

Дык табуретка-то всегда будет. В нынешних ОС, во всяком случае. Но не надо делать стол с криками "смотрите как он похож на табуретку - вы так же удобно сможете на нем сидеть, но при этом будет куда поставить тарелку!" Пусть стол будет столом.

>> Возможно, есть люди, способные держать в голове все переопределения в большом проекте. Они, встречая a = b, сразу представляют именно тот код, который отрабатывается в этом месте (ну или уверены в том, что его нет). Для любых a и b, которые могут оказаться в тексте проекта.

не так уж много типов возможно для a и b
без потери логической цельности
и в общем то
определение оператора = это уже часть архитектуры

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

>>> ??? Скомпилил и заработало. Где ошипка?;)

у вас всегда будет b:callme
не зависимо от правил вызова виртуального метода

>>> Дык табуретка-то всегда будет. В нынешних ОС, во всяком случае. Но не надо делать стол с криками "смотрите как он похож на табуретку - вы так же удобно сможете на нем сидеть, но при этом будет куда поставить тарелку!" Пусть стол будет столом.

с++ не стол, а табуретка
наличие скамеечки С создает видимость что это стол
но это не правильно
забудте о его использовании как стола

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

кстати и для java -
unix - чужеродная среда
java вынуждена сначала эмулировать платформу java

жаль, что, как платформа - java не минималистична
возможно, тогда бы, она была-бы вторым поколением Unix :)))

А можно для простоты понизить зарплату Страуструпу?;)

> у вас всегда будет b:callme не зависимо от правил вызова виртуального метода

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

> забудте о его использовании как стола

Что-то у нас с метафорами не так;) Вы мне предлагаете забить на ООП в С++?;)

> жаль, что, как платформа - java не минималистична

j2me ;)

>> А можно для простоты понизить зарплату Страуструпу?;)

уже поздно он на пенсии
во вторых - как бы это сказать
а K&R - посадить за хулиганство ?
-- Вы переходите на личности при этом в грубой форме ....
не надо - портите впечатление о Вас

>> у вас всегда будет b:callme не зависимо от правил вызова виртуального метода
> В плюсах виртуальный метод, вызванный из конструктора базового класса, реально приведет к исполнению кода базового класса (ну или какой там метод был доступен на момент вызова конструктора), не окончательного (производного класса).

у Вас ошибка - описка в Вашем коде - приглядитесь

>> забудте о его использовании как стола
> Что-то у нас с метафорами не так;) Вы мне предлагаете забить на ООП в С++?;)

метафоры опасный путь, обсуждались только величина - объем - простота
я предлагаю не 'забить', а не предъявлять требования к табуретке c++
как к столу

>> жаль, что, как платформа - java не минималистична
> j2me ;)

j2me - все еще очень крупная вещь

кстати некоторые возможности невозможности java
это чисто маркетинговый ход сан ....

> а K&R - посадить за хулиганство ?

Условно;)

> -- Вы переходите на личности при этом в грубой форме ....

Ну вы ж понимаете - в данном случае Страуструп не личность, а функция (аффтор плюсов) - так что позволю себе иногда на него переходить;)

> у Вас ошибка - описка в Вашем коде - приглядитесь

Тьфу, ну да. В a.callme выводиться должно a.callme (выводится b.callme в любом случае, проверено). Спасибо за коррекцию;)

> предъявлять требования к табуретке c++ как к столу

Дык он пыжится быть столом...;) Мда, что-то меня заклинило на этой метафоре;)

> j2me - все еще очень крупная вещь

Ну какая же она крупная, если ее запихивают в самые хиленькие телефончики?...

> кстати некоторые возможности невозможности java это чисто маркетинговый ход сан ....

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

>Ю j2me - все еще очень крупная вещь
> Ну какая же она крупная, если ее запихивают в самые хиленькие телефончики?...

в данном случае - достаточно малая -
это остаться в виде заголовочных фалов ;)
как posix
как elf

понимаете ?

Ну... такой минимализм остался в 70-80х... Ну или у исследователей да гиков...;)

>> Ну... такой минимализм остался в 70-80х... Ну или у исследователей да гиков...;)

значит Пайк был прав - наблюдается стагнация в осестроении
и Unix выполнил свою задачу - остановил развитие

> Я ж говорил многократно - беда плюсов не в коде, написанном как надо. А в коде, написанном в процессе наступания на все грабли, которые раскиданы в этом языке - пока человек не научится писать как надо.
С этим не могу не согласиться, ты прав. Я тебя сначала просто не так понял. Но ведь тут больше проблема не языка, а людей, которые его используют. Хотя конечно C++ можно было лучше спроектировать, сделать более дуракоустойчивым.

>> Кратко хотя бы. Основные тезисы.
> Выше приведены;)
Да точно. Тоже все верно, возражений нет.

>> Давай лучше на "ты", если не возражаешь. Не люблю весь этот англо-американский официоз
> Можно попробовать. Только англо-американскость не при чем - обращение на "Вы" по умолчанию к малознакомому(незнакомому) человеку давно было нормой русского языка, не так ли?
Да, но эта одна из тех норм, которые мне совсем не нравятся. Это только лишние барьеры создает в общении IMHO. И уж вовсе не является показателем отношения к человеку. Да и LOR я читаю давно, поэтому сказать, что ты для меня малознакомый человек тоже не могу.

> По поводу хинтов - вопрос понял. Я не уверен, что у гнома есть свои (впервые об этом слышу). Всю дорогу казалось, что гном просто стандартизовал через fd.o и EWMH все, что ему нужно было;)

Забавно, а что же тогда в нашем FVWM за поддержка GNOME hints. Может у вас в 1ом GNOME что-то подобное было, что затем было отвергнуто?

я кажется понял что именно Вам не нравиться в плюсах
кратко это можно выразить

value == object vs object == interface

что тут сказать - это разные модели
c# пытается их помирить, но меня лично пугает его перегруженность

если вы видите что в проекте доминирует идеология value == object
то это с++ проект
если object == interface - то это java проект

мне лично хотелось бы видеть переход value == object -> object == interface
на уровне системы
наличие такого перехода я бы и назвал минимальной реализацией java

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

Дада, абстрактно хорошему языку С++ досталась плохая планета. Негодная. Людишки на ней... Так себе людишки, ленивые мозгом...;)

> Хотя конечно C++ можно было лучше спроектировать, сделать более дуракоустойчивым.

Вот!

> Это только лишние барьеры создает в общении IMHO.

Будучи склонным к мизантропии, не считаю барьеры злом;) Просто надо находить момент, когда их можно убирать. И выбирать тех, с кем можно себе это позволить;) НЕ АНОНИМУСОВ, как минимум;)

> Забавно, а что же тогда в нашем FVWM за поддержка GNOME hints. Может у вас в 1ом GNOME что-то подобное было, что затем было отвергнуто?

Возможно, название было внесено в FVWM когда еще не было fd.o и хинты не были стандартизованы?

> мне лично хотелось бы видеть переход value == object -> object == interface

Вроде что-то такое хотела сделать BeOS, если я ничего не путаю. Впрочем, да, суть моих претензий к ОО идеологии плюсов выражена, в общем, верно. На всякий случай - претензии по maintainability price плохого кода идут по другой статье.

>> Но ведь тут больше проблема не языка, а людей, которые его используют.
> Дада, абстрактно хорошему языку С++ досталась плохая планета. Негодная. Людишки на ней... Так себе людишки, ленивые мозгом...;)

нам всем досталась плохая планета
но ничего не остается как продолжать жить на ней

>> Хотя конечно C++ можно было лучше спроектировать, сделать более дуракоустойчивым.
> Вот!

прекратите оба !
с++ должен быть таким какой он есть
так как, покрайней мере, он единственный носитель иделогии value == object
только для того что-бы сохранить оную в культуре,
он должен продолжать существовать

>> мне лично хотелось бы видеть переход value == object -> object == interface

> Вроде что-то такое хотела сделать BeOS, если я ничего не путаю. Впрочем, да, суть моих претензий к ОО идеологии плюсов выражена, в общем, верно. На всякий случай - претензии по maintainability price плохого кода идут по другой статье.

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

> только для того что-бы сохранить оную в культуре, он должен продолжать существовать

Для лучшей сохранности предлагаю сдать в музей%)

(У меня уже пятничное настроение;)

> Для лучшей сохранности предлагаю сдать в музей%)
> (У меня уже пятничное настроение;)

можно оставить у меня
:)) мне эта игрушка нравиться :))

> Один из базовых selling points плюсов - реюзабельность кода. Как же код может быть реюзабельным, если применимость иерархии классов в общем случае ограничена тем проектом, на который она изначально рассчитывалась?;)

Какой интересный аргумент... А где необходимость использовать _всю_ иерархию классов одного проекта в другом? Зачастую достаточно использовать один или несколько базовых классов.

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

> мне лично хотелось бы видеть переход value == object -> object == interface на уровне системы

The Microsoft Component Object Model (COM) :-)

>Возможно, есть люди, способные держать в голове все переопределения в большом проекте. Они, встречая a = b, сразу представляют именно тот код, который отрабатывается в этом месте (ну или уверены в том, что его нет). Для любых a и b, которые могут оказаться в тексте проекта.

Но ведь a.assign(b) тоже не гарантирует сего для любых a и b. А вдруг, некоторые сочетания творят rm -rf / или еще какую гадость;) Мало ли чего кодеры наперегружали...

>Это типы данных, позволяющие адресовать произвольный кусок памяти. А вот это - зло.

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

>Да вообще надо было оставить табуретку С в покое, если взялись строить ОО язык. А байндинги к сишным библиотекам построить всегда можно, как показывает опыт мульона других языков (ОО и не очень).

Взялись ведь строить C with classes, а потом понравилось. Т.е. обычная эволюция, в отличие от "революции" java...
Зачем байндинги, если можно на том же языке писать низкоуровневую и высокоуровневую часть просто в разных модулях.

Вообще, вероятно, один из немногих недостатков C++ является отсутствие столь всеобъемлющей стандартной библиотеки на все случаи жизни, как в java.

>value == object vs object == interface

В плюсах никакого "vs" нет. Как нет его в Ada или Eiffel. 
Есть "object by value" и "object by reference". 
"object by reference" в плюсах - похоже на жабский 
"object by reference". Только помощней. Ибо в С++ мы можем иметь 
например объекты - константы.


Class X {
 ...
};

X const& x = *new X; // с x доступны только операции помеченные как const - компилятор проследит.
В жаба же можно только (выражаясь в терминах С++)

X& const x = ...;

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

> если вы видите что в проекте доминирует идеология value == object то это с++ проект если object == interface - то это java проект


Ну это конечно нетак. Более того - это смешно.