> На С++ похоже) На выходе gob дает чистый С, а программист работает только с gob-файлами. Я правильно понял?

В общем, идея именно такая. Да, на С++ похоже. Но попроще.

> А Makefile как в этом случае поддерживается?

А в чем проблема? В одном target генерите .c/.h из gob, в другом - компилите. Второй target зависит от первого.

> А подключение заголовочных файлов почему отсутствует?

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

> Про gob сегодня вообще первый раз услышал. Поэтому для меня что gob, что gok...))

Верю. Просто мне немного стыдно:)

Re: Re: Re: Re: Ух, ну вааще. swing и перл и tcl умеет. Крутые ребята. Базовые-то средства tcl только С кушали.

Правда, это все-таки не снимает проблем нестабильного ABI - ведь даже хитропопый swing, небось, обломается на модулях, скомпиленных не той версией gcc. Или не обломается?

swig

>Забавно. swig могуч. Интересно будет посмотреть, как они это делают...

Наверное, завязались на ABI С++, который делает gcc и все. Вот изменится спецификация ABI - swig придется менять. А может быть, прослойку сишную создают. Кто работал - прояснит. Лень искать сейчас самому. :)

>То же самое? Если переопределены конструктор копирования A(B& b) и оператор присваивания =(B& b)?

Изначально это то же самое. "Побитовое" копирование. А вот когда пользователь там чего-то уже переопределил -
ответственность несет сам)

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

Давно уже) Поэтому мне интересно, как дела с этим сейчас: можно ли слинковать два модуля, скажем, один откомпилированный Intel-компилятором, второй - gcc. Теоретически да, а практически - не доводилось?

>Там есть deprecated методы (и даже классы!), которые сохранены для совместимости, но рекомендуется использовать другие. Нельзя же забывать про существующие приложения...

Если для совместимости - то понятно. Я думал там что-то архитектурно-принципиальное...

>Про это я не слыхал. Мне кажется, это уже происки пуристов:)

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

> А вот когда пользователь там чего-то уже переопределил - ответственность несет сам)

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

Про линкование интеловских объектников и gcc-шных ТОЧНО сказать не смогу. Но и ругани не было. При том, что динамические библиотеки, построенные gcc (например, glibc) используются программами, собранными intel-ом - делаю вывод, что совместимость, вроде, есть. Но, повторяю, сам не пробовал. Могу ошибаться.

>Еще как. Есть даже круче: private protected!:)

Шутка?

> Если для совместимости - то понятно. Я думал там что-то архитектурно-принципиальное...

Нет. Я просто хотел показать, что не все, что public - стОит использовать. Чтение доков полезно в любом случае. А если девелопер их читал - он и в случае с gtk не будет вызывать ненужных методов:). Конечно, лишняя защита со стороны компилятора - полезна, однозначно. Но она не решает всех проблем - и не освобождает от чтения документации по API.

Правда. private protected есть на самом деле.

Точнее, был в первой версии жабки. Потом убрали. Я сам его реально никогда не пользовал:)

Возвращение к корням

А тема, я напоминаю, миротворческая миссия Novell ... :)

Сишные компиляторы

>Про линкование интеловских объектников и gcc-шных ТОЧНО сказать не смогу. Но и ругани не было. При том, что динамические библиотеки, построенные gcc (например, glibc) используются программами, собранными intel-ом - делаю вывод, что совместимость, вроде, есть. Но, повторяю, сам не пробовал. Могу ошибаться.

Думаю, что все-таки в рамках одной платформы (скажем PC) и/или операционной системы есть какие-то соглашения по вызовам в Си. Ведь Win API весь уже в dll скомпилирован, имеет сишный интерфейс. А между тем им спокойно пользуются все мне известные компиляторы C/C++. И даже те, которые к Cи ним не имеют никакого отношения (Deplhi, например).

>А язык, в котором легко сделать такую "ошибочку" как использование одной функции вместо другой (на самом деле даже двух вместо одной - там ведь еще конструктор по умолчанию во втором случае работает)? При том, что код выглядит так похоже и, казалось бы, настраивает на мысль об одинаковой семантике (или это только мне так кажется?). Такой язык отвественность за действия программиста не несет? В этом я и вижу беду С++ как языка (безотносительно к вопросу об интерфейсах) - он не хочет нести ответственность за ложное понимание его тонкостей. А их есть у него. Почему один и тот же символ "=" означает два совсем разных оператора? Почему соглашения на этот счет столь запутаны и сложны? Так и надо?

Да. У них, как минимум, различные типы возвращаемых значений.
Хотя реализация почти всегда одинакова. Правда, в третьем случае надо дополнительно обрабатывать вариант a = a;
Но программист, который переопределяет такие вещи, всегда должен помнить об этом.

A a = b; // A::A(const A&) { ... };
A a; // A::A(); { ... };
a = b; // A& A::operator=(const A&){ ... return *this; };

Мы обязательно должны попасть в топ! :)... Так что если я буду нести пургу, то знайте - иду на рекорд :)

>Мы обязательно должны попасть в топ! :)... Так что если я буду нести пургу, то знайте - иду на рекорд :)

В принципе, могу помочь, но мне через полчаса домой :(
Разве что для следующей недели место забить)

>А их есть у него. Почему один и тот же символ "=" означает два совсем разных оператора?

Я еще поищу подробных объяснений по этому поводу у Стауструпа. Если найду чего интересного, сообщу.

Да я это все понимаю. Мне не нравится что за такими ПОХОЖИМИ кусками кода могут скрываться совершенно разные результаты.

> Хотя реализация почти всегда одинакова.

А вот это уже нечестно. Либо вы уж как-нибудь выкрутите программисту руки, чтобы реализация не могла быть неодинакова - либо не дайте сделать код таким ВИДИМО одинаковым при совершенно разном поведении.

Боюсь, до топа еще далеко. На след. неделе можем договорить - архив-то всегда с нами. Я еще часа 2 точно буду.

Дискуссия на OSNEWS

На OSNEWS тоже идет дискуссия по этой теме

http://www.osnews.com/comment.php?news_id=6463

Ждем-с:)

Только что поигрался с компилятором. Нашел еще одно оправдание для С++:
мы можем написать:
return a = b;
но не можем:
return int a = b;
потому что после этих двух случаев содержимое регистра AX (или как его там) будет различно.

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

>Ждем-с:)

Долго ждать. Страуструп дома)

????

> return int a = b; > потому что после этих двух случаев содержимое регистра AX (или как его там) будет различно.

Такого же действительно не бывает! И дело не в ax, а в том, что объявление переменной не является работающим кодом, не имеет возвращаемого значения.

Т.е. С как раз чист - он не дает двух видимо похожих конструкций с потенциально разным результатом (и это хорошо). Вторая конструкция просто неправильна и отсекается компилятором.

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

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

Что-то я Вашу мысль не очень понял, сорри. В плюсах, когда переменная-объект класса инициализируется - совершается некий магический ритуал (в отличие от С, где переопределить ничего нельзя). Во первых, синтакс этого ритуала не однозначен (ну кто бы запретил Страуструпу разрешить только A a(b)?) Во-вторых, дает возможность спутать его с тривиальной операцией присваивания. Лично для меня мораль этого действия - плохая продуманность спеков в этом месте. Либо надо было запретить синтакс A a=b (самое простое решение - но у Страуструпа была священная корова видимой совместимости с С, которая для объектов все равно смысла не имеет), либо как-то (не знаю как, не спрашивайте) жестко связать операции инициализации и копирования (кстати, тут еще в памяти всплывают проблемы полиморфизма при копировании - не сталкивались?).

точно были. при пробе брать обджекты от борланда и ваткома

> Или покажите исследования независимого коллектива специалистов по юзабилити.

"XP vs Mac vs Linux" http://www.pcworld.co.nz/PCWorld/pcw.nsf/0/ACC21A8F154C34B0CC256AED006F7668?O... ROUND THREE: USABILITY Winner: Linux/KDE 2

Gnome в силу его убогости даже не рассматривается... :)

> Gnome в силу его убогости даже не рассматривается... :)

Бездоказательно, сир, бездоказательно. Вот если бы рассмотрели и сказали: "Фу-у.. Как убого!" - тогда другое дело. Вообще, странный обзор. Макос выиграл 2 раза, винхп - 1.5 При этом общий выигрыш - у винюков. Они бы тогда хоть весовые коэффициенты категорий опубликовали, что ли?

> Бездоказательно, сир, бездоказательно.

Вы хотели официоза - их есть уменя. Это не похождения гика с osnews.org. Или у вас есть более уважаемые эксперты? :)

>Живите, конечно, живите. Просто не претендуйте на те ниши, где С++ >не годится. И не считайте, что С++ является идеальным сочетанием >высокого уровня ОО и скорости С. Только за эти пункты я и воюю с >плюсами.

Фигня это все ASM рулит! А вообще можно и на том и на этом писать. Историю помните: C++ - был написан на C с использованием препроцессора (вся классовая фигня). Потом уже был написан компилятор, так что можно и то и другое написать, главное уметь....

Как говорится плохому танцору - мешают плохие яйца.... :)

Нет. Просто Ваш официоз какой-то хиленький получился:)

> скажем, один откомпилированный Intel-компилятором, второй - gcc. Теоретически да, а практически - не доводилось?

Доводилось. Линковал быблиотеки на gcc 3.3 к 7-му интелу. Работает, хоть на Си, хоть на Фортране. C++ не пробовал, но, скорее всего, НЕ работает.

> С точки зрения удобства UI -- на голову впереди.

Ууу. Я бы не сказал. Меня например тошнит от тысяч кнопочек и надписей, выведеных на основной экран, как в Windows и KDE, называемых фичастостью.

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

Да ты видел вообще KDE? Plastik, Keramik? Не то, что поносные цвета, убогие плоские кнопки в GNOME. И уж тем более Industrial - вообще X Athena Widgets напоминает. Фу говно.

2 svu: Да, насчет private virtual забыл ответить. Что-то мне лень писать, но можешь посомтреть вот тут

http://www.le-hacker.org/papers/gobject/index.html

Кажется в разделе "Object Methods".

> Что-то я Вашу мысль не очень понял, сорри. В плюсах, когда переменная-объект класса инициализируется - совершается некий магический ритуал (в отличие от С, где переопределить ничего нельзя). Во первых, синтакс этого ритуала не однозначен (ну кто бы запретил Страуструпу разрешить только A a(b)?) Во-вторых, дает возможность спутать его с тривиальной операцией присваивания. Лично для меня мораль этого действия - плохая продуманность спеков в этом месте. Либо надо было запретить синтакс A a=b (самое простое решение - но у Страуструпа была священная корова видимой совместимости с С, которая для объектов все равно смысла не имеет), либо как-то (не знаю как, не спрашивайте) жестко связать операции инициализации и копирования (кстати, тут еще в памяти всплывают проблемы полиморфизма при копировании - не сталкивались?).


В первых реализациях С++ был только operator=, поэтому программисту для копирования своих объектов приходилось определять лишь эту функцию.

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

Что касается реализации в С. В первых версиях С, насколько мне известно (если не прав, поправьте) такая конструкция тоже была запрещена:
int a = b;
И тоже была введена позже. И, наверняка, по тем же причинам.
Именно в С оператор = стал впервые выполнять 2 различные операции: присваивание и инициализацию.
С различным результатом, прошу заметить.
Вот поэтому в С++ тоже два таких "оператора" для двух различных поведений.

Спасибо за экскурс в историю. Все-таки я не зря подозревал, что тут дело нечисто. Оказывается, конструктор копирования был введен не сразу, а когда выяснилось, что без него получаются тормоза. Ну хорошо, но что же помешало им оставить ЕДИНСТВЕННЫЙ синтакс A a(b)? Все-таки было бы как-то однозначнее и приличнее - и никто бы не путал инициализацию с присвоением...

> Именно в С оператор = стал впервые выполнять 2 различные операции: присваивание и инициализацию.

> С различным результатом, прошу заметить.

Штука в том, что инициализация в С не имеет других результатов, кроме инициализации. И присвоение отличается от нее только тем, что возвращает значение. В С++ же за этими операциями может стоять все, что угодно, вплоть до рестарта Вселенной (причем двумя различными способами).

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

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

Спасибо за ссылочку. Только не такие уж они приватные. Все-таки ничто мне не помешает вытащить из объекта - класс, из класса - указатель. И дернуть за него. Так что лукавят ребята:) Я думаю, действительная приватная виртуальность возможна только через извраты со стандартизацией приватной части класса (типа, в каждом классе делать PrivateClassPart * private - и как-то вводить соглашения по устройству этого куска памяти). Все остальное не дает гарантированной защиты.

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

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

>Ну хорошо, но что же помешало им оставить ЕДИНСТВЕННЫЙ синтакс A a(b)? Все-таки было бы как-то однозначнее и приличнее - и никто бы не путал инициализацию с присвоением...

Из-за шаблонов. См. ответ ниже.

>На самом деле, тут половина моих претензия адресована к неоднозначному смысла символа "=", вторая половина - к переопределению операторов вообще, как явлению в жизни С++. Когда я переходил с плюсов на жабку, меня очень огорчило, что я не могу переопределять операторы. Потом, через некоторое время, я посмотрел назад и подумал: "Боже, как хорошо, что операторы в жабке переопределять нельзя!" Количество потенциальных, спрятанных проблем от перегрузки, по моему мнению и опыту, превышает количество пользы от немного сократившегося кол-ва кода. Перегрузка, мне кажется, была реверансом в сторону математиков. А пользуются ей все, кому не лень и как попало. И получаем...

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

Причина, как это часто бывает в жизни, крылась на самом деле в другом. В шаблонах.
С самых первых версий С++ Страуструп хотел добавить в язык поддержку шаблонов.
И хотя их в язык добавили одними из самых последних, наверное, но это факт: их хотели добавить еще во 2 версии С++.
Так вот, шаблоны должны были корректно работать и с встроенными типами, и с пользовательскими.
Если не разрешить перегрузку операторов, то ни о каких шаблонах речь уже не могла идти.
Потому что встроенные типы могли работать только с операторами, не хотите же вы в шаблонах писать так:
T a, b, c, d, e;
a = summ(a, summ(b, summ(c, summ(d, e))));
вместо привычного a = a + b + c + d + e ?

Я слышал, в Java хотят добавить шаблоны?
Думаю, появятся там и пользовательские операторы к такому празднику.

Кстати, именно из-за шаблонов Страутруп хотел сделать синтаксис работы со встроенными типами аналогично синтакису работы с классами.
Вот Вам и ответ, почему он не мог довольствоваться единым синтаксисом A a(b).


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

Чего-то я не понял.

> Спасибо за ссылочку. Только не такие уж они приватные. Все-таки ничто мне не помешает вытащить из объекта - класс, из класса - указатель. И дернуть за него. Так что лукавят ребята:) Я думаю, действительная приватная виртуальность возможна только через извраты со стандартизацией приватной части класса (типа, в каждом классе делать PrivateClassPart * private - и как-то вводить
соглашения по устройству этого куска памяти). Все остальное не дает гарантированной защиты.

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

> Так в книжках пишут, что переопределение операторов было реверансом для математиков. Не верьте им)

Да, в книжках? Чорт, а до меня это только сейчас дошло:) Или я где-то прочел, потом забыл, потом вспомнил как свое:)

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

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

> T a, b, c, d, e;

> a = summ(a, summ(b, summ(c, summ(d, e))));

> вместо привычного a = a + b + c + d + e ?

??? Что-то я не понял. По-моему, шаблоны и операторы ортогональны (да, кроме встроенных типов, но тут Вам может помочь автобоксинг, как его зовут в C#). И меня совсем не корежит функциональный синтакс. Только это будет так

a = a.summ(b).summ(c).summ(d).summ(e).

По-поему, неплохо. Правда, я, сорри, сейчас уже точно не помню, кто в плюсах суммируется сначала a + b или d + e - ох уж эти мне правила группировки в операторах (давно я не упражнялся:) И тут мы касаемся другой "особенности": когда пишешь "+" - должен четко представлять, будет вызван глобальный оператор или определенный в классе (список правил определения этого факта прилагается:)

> Я слышал, в Java хотят добавить шаблоны?

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

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

Кажется, я понял. Если действительно принять Вашу версию, что переопределение порождено стремлением уравнять все типы данных в правах на шаблоны, то это была вредная идея. Вариантов, которые позволили бы избежать этого, два: запретить шаблонам использовать примитивные типы или организовать автобоксинг. Впрочем, второй вариант убил священную корову совместимости с С (которая все равно полуживая, поскольку не весь код С компилится плюсами - и, говорят, С99 во многих аспектах уходит "вбок" относительно линии развития С++ - поэтому несовместимость, типа, будет прогрессировать - но это слухи, могу ошибаться).

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

> Чего-то я не понял.

Если у Вас есть someFunction (SomeClass *p1, BaseClass* p2) и someFunction( SomeClass* p1, DerivedClass* p2), то в случае, когда переменная BaseClass *var передается вторым параметром - всегда будет вызван первый метод, даже если реально var указывает на объект DerivedClass. Народ чаще наступает на эти грабли, если someFunction является переопределенным оператором.

> Даже в С++ можно обойти защиту и получить доступ к приватной части. > private предназначен для защиты от непреднамеренных случаев доступа.

Ну, мы же говорим про легальные методы доступа. В плюсах для этого придется корежить заголовочные файлы (остальные методы нечестны и привязыны к конкретной реализации). А в glib просто сделать строчку вызова чуть подлинее.

>??? Что-то я не понял. По-моему, шаблоны и операторы ортогональны (да, кроме встроенных типов, но тут Вам может помочь автобоксинг, как его зовут в C#). И меня совсем не корежит функциональный синтакс. Только это будет так

>a = a.summ(b).summ(c).summ(d).summ(e).

>По-поему, неплохо. Правда, я, сорри, сейчас уже точно не помню, кто в плюсах суммируется сначала a + b или d + e - ох уж эти мне правила группировки в операторах (давно я не упражнялся:) И тут мы касаемся другой "особенности": когда пишешь "+" - должен четко представлять, будет вызван глобальный оператор или определенный в классе (список правил определения этого факта прилагается:)

А если для a, b, c, d, e
T = int
То компилятор выдаст ошибку на a = a.summ(b).summ(c).summ(d).summ(e) ?


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

Что такое "автобоксинг"?

Мне вот сотрудники подсказывают, что в C# тоже есть пользовательские операторы.
А если в Java шаблоны не будут поддерживать простые типы, то это очень большой минус.
Сразу же в Sun посыпятся жалобы.

>Впрочем, второй вариант убил священную корову совместимости с С (которая все равно полуживая, поскольку не весь код С компилится плюсами - и, говорят, С99 во многих аспектах уходит "вбок" относительно линии развития С++ - поэтому несовместимость, типа, будет прогрессировать - но это слухи, могу ошибаться).

Да, это правда. С99 увел в бок С, и Страутруп этому не сильно рад.
Совместимость с С никогда не была 100% и никогда не будет. С самого начала предполагали, что она будет "максимальной", без определения степени максимальности. Чтобы было 100% - надо объединить комитеты С и С++ со всеми вытекающими...

> Что такое "автобоксинг"?

Это автоматическая генерация кода, который делает из примитивного типа int объект класса Integer (сорри за жабский синтакс) и наоборот - в зависимости от контекста. Работает в С# и Java 1.5 (возможно, в других, менее попсовых языках, наверное, в Smalltalk). Тогда в случае template просто будет использован (если не в синтаксисе, то в сгенерированном коде) класс Integer, у которого вполне может быть метод summ (давайте все-таки add, хорошо?:) Компилятор с поддержкой autoboxing прекрасно позволит Вам использовать примитивные типы - и без перезагрузки операторов. Кстати, автобоксинг делает жабку чуть более ОО, чем раньше - уж очень некрасиво выглядел тот факт, что не все типы данных равны. Все-таки в полностью ОО языке все должно быть объектом. Жабке до этого идеала очень далеко, но автобоксинг чуть приблизил ее.

> Мне вот сотрудники подсказывают, что в C# тоже есть пользовательские операторы.

Популистская мера MS:) Зря они это. Хотя, при том, что там есть и указатели - чего уж там...

> Сразу же в Sun посыпятся жалобы.

В Сан жалобы на операторы начали сыпаться с первой жабы и постоянно сыпятся. Думаю, поток жалоб со временем утихает:) И введение темплейтов (одновременно с автобоксингом!) не увеличит плотность потока, я думаю.

> Ну, мы же говорим про легальные методы доступа. В плюсах для этого придется корежить заголовочные файлы (остальные методы нечестны и привязыны к конкретной реализации). А в glib просто сделать строчку вызова чуть подлинее.

Ничего не надо корежить. Работает на всех реализациях.

#include <stdio.h>

class A
{
int p;
public:
A() { p = 1; }

};


int main()
{
A a;
int* p =(int*) &a;
++*p;
printf("%d\n", *p);
return 0;
}

Виноват. Плохо определил обсуждаемую область. Я говорил о приватных виртуальных методах.

(И вообще, я же тут С++ хвалю за реализацию защиты на уровне компиляторы, Вам бы меня поддерживать надо, как любителю плюсов, а Вы спорите:)

Скорее, не приватных, а protected (приватная виртуальность все-таки бессмысленна, наверное).

> Да, это правда. С99 увел в бок С, и Страутруп этому не сильно рад.

А может, это С++ ушел в бок?:) Все относительно в этом мире...

> Совместимость с С никогда не была 100% и никогда не будет. С самого начала предполагали, что она будет "максимальной", без определения степени максимальности. Чтобы было 100% - надо объединить комитеты С и С++ со всеми вытекающими...

А вот интересно, можно ли было бы определить стандарт С++ как diff к стандарту С? Может, и бредовая идея - но все-таки интересно. Тогда, допустим, вышел бы стандарт С99 - а к нему, в виде diff, С++2001 - и тогда совместимость могла быть получше... Т.е. вообще, мне лично идея совместимости с С кажется вредоносной для С++, но уж если объявили ее священной коровой - могли бы и побороться за ее жизнь. А если "без объявления степени максимальности", то я так и жабку могу совместимой назвать. Например for (int i=0;i<10;i++) {} компилится и жабкой, и С:)

> Это автоматическая генерация кода, который делает из примитивного типа int объект класса Integer (сорри за жабский синтакс) и наоборот - в зависимости от контекста.

Ну и о какой эффективности здесь может идти речь?
А высокая эффективность была одной из главных целей при разработке С++.
Не зря ведь говорят, что sort из С++ работает быстрее, чем qsort из С ;)

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

Может быть. И много Вы знаете таких "полностью ОО" языков?

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

Да, именно это и призван в С++ делать operator+(). То есть, Java - это "менее ОО" язык, чем С++?

>(И вообще, я же тут С++ хвалю за реализацию защиты на уровне компиляторы, Вам бы меня поддерживать надо, как любителю плюсов, а Вы спорите:)

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

> А может, это С++ ушел в бок?:) Все относительно в этом мире...

Можно и так сказать. Только если учесть, что разработчики "С" очень активно сотрудничили со Страуструпом над "С++", то я бы сказал, что С++ - это следующая версия С.

> А вот интересно, можно ли было бы определить стандарт С++ как diff к стандарту С? Может, и бредовая идея - но все-таки интересно. Тогда, допустим, вышел бы стандарт С99 - а к нему, в виде diff, С++2001 - и тогда совместимость могла быть получше... Т.е. вообще, мне лично идея совместимости с С кажется вредоносной для С++, но уж если объявили ее священной коровой - могли бы и побороться за ее жизнь. А если "без объявления степени максимальности", то я так и жабку могу совместимой назвать. Например for (int i=0;i<10;i++) {} компилится и жабкой, и С:)

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

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

> Ну и о какой эффективности здесь может идти речь?

Ну да, эффективность теряем. Чего уж там спорить... Зато безопасность разработки была бы выше. Уверен, что в 90% случаев это важнее. Для остальных - помог бы кусочек кода на С.

> Не зря ведь говорят, что sort из С++ работает быстрее, чем qsort из С ;)

Это очень интересно. А где про это можно почитать? И как оно удалось? Или все-таки "смайлик"?:)

> То есть, Java - это "менее ОО" язык, чем С++?

В смысле отношения к примитивным типам - да. Есть и другие стороны, мы о них не будем. Правда, жаба 1.5 приблизила простые типы к классам - поэтому в этом аспекте догнала С++:)

> Просто хотел добавить, что абсолютная защита в языке не имеет смысла.

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

> Можно и так сказать. Только если учесть, что разработчики "С" очень активно сотрудничили со Страуструпом над "С++", то я бы сказал, что С++ - это следующая версия С.

Брукса ("MMM") читали? Там есть замечательные строки про вторую систему...:)

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

А как сейчас - оно лучше?

> Выход, который предлагает Страуструп - объединить языки (комитеты), и сделать С подмножеством С++. Выиграют от такого шага все: от пользователей до разработчиков компиляторов. Но двигаться навстречу друг другу надо всем, а не только разработчикам С++. Но, похоже, те, кто принимали С99, этого не понимают. Или делали это нарочно.

Вот оно, наследование по С++: сделать производный класс зависящим от базового!:))) Я думаю, разработчики С99 пытались реально решить те проблемы, которые возникают в С при НЕИСПОЛЬЗОВАНИИ С++ (и без ОО на уровне языка). А С++ решает эти же проблемы при помощи ОО. То решение, которое предлагаете Вы, отводит мощному языку ВЫСОКОГО УРОВНЯ роль какого-то ассемблера для С++. Т.е. если программисту на С не хватает чего-то, ему говорят: "Смотри, в С++ это делается так просто ..." и все. Это бы означало смерть С как самостоятельного языка. Я думаю, есть смысл в том, чтобы С развивался и рос без оглядки на С++. А вот С++, единожды задекларированный как производный от С, действительно должен смотреть, куда дует ветер С. Или просто однажды честно сказать: "Да пошел этот С с его развитием!.. Вот я буду совместим со стандартом 10-летней давности, а дальше буду делать, как мне кажется удобным, логичным, ..."