> Что такого ужасного ты нагуглил?
Ну вот это, я уже приводил ссылку: http://qt.osdn.org.ua/binarycompat.html

Правда, это про КДЕ, а не "чистый" С++, но всё-таки.
"Вы не можете ...
* добавлять новые виртуальные функции, так как это изменит таблицу виртуальных функций и приведет к неработоспособности наследуемых классов. ( Однако в некоторых случаях это все же возможно - спрашивайте в группах рассылки ).
* Изменять порядок виртуальных функций в объявлении класса. Это наверняка приведет к измене содержимого таблицы виртуальных функций.
* Изменять сигнатуру функции. Заметьте, что расширение функции еще одним параметром, даже если этот параметр имеет значение по умолчанию, приводит к изменению сигнатуры функции. Поэтому такое решение не обеспечивает бинарную совместимость ( только совместимость на уровне исходного кода )...
* Добавлять новые данные-члены в класс или менять их очередность в объявлении ( не применимо к статическим данным ).
...
"Самой большой проблемой при написании библиотек является невозможность безопасного добавления новых данных-членов, так как это приведет к изменению размеров и расположения каждого класса, структуры и массива, содержащих объект этого типа, включая наследуемые классы."

Ну и так далее.

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

> в Лиспе и прочих функциональных и/или интерпретируемых языках - свои пакеты

Причём, у каждой реализации своё представление о пакетах, а FAS (байткод или уже готовый машинный код) так вообще даже между версиями одной реализации не обязаны быть совместимыми.

> "Вы не можете ...

Если ты приглядишься, то увидишь ровно те же ограничения в Си.

>> "Вы не можете ...

>Если ты приглядишься, то увидишь ровно те же ограничения в Си.

Демагогия.

Глупости не говори. Есть мелкие ограничения, но проблем с ними особо не возникает, а тут - настоящий ад перекомпиляций и множества версий одной либы в одной ОС. Я уж не говорю о принципиальной невозможности безкостыльного динамического связывания с библиотекой на С++

>> Если ты приглядишься, то увидишь ровно те же ограничения в Си.

> Демагогия.

Реальность. Добавь поле в Си-структуру - получи несовместимый ABI. Измени сигнатуру - получи то же самое.

>> "Вы не можете ...
> Если ты приглядишься, то увидишь ровно те же ограничения в Си.

Но там ведь нету виртуальных функций, сигнатур функций, данных-членов класса. Или я там не смогу добавить данные-члены в структуру?

> ад перекомпиляций

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

Ты поэт.

>Это не столь важно?!

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

>это критично

Нет. Не всем нужна переносимость между различными платформами.

>хуже

Обоснуй.

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

А виндовые DLL тоже этим страдают? Или я не очень это понимаю? :-)

>А для тебя освоить язык - проблема?

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

> Но там ведь нету виртуальных функций

Там есть таблицы функций.

> сигнатур функций

У любой функции есть сигнатура.

> данных-членов класса.

Их вполне заменят поля структур.

> Или я там не смогу добавить данные-члены в структуру?

Без обид, но ты вообще Си++ или Си знаешь?

Хохо. Редко нужно менять кол-во полей в структуре. Обычно такое случается только во время смены major версии либы. Часто меняются структуры в UNIX API? А те пункты про виртуальные ф-ии - вот это меняется каждый день.

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

Вы хотя бы представляете себе, что это за трудозатраты - создавать сишный интерфейс для с++-х библиотек? В человеко-днях? Это надо взять GObject, да?

> А те пункты про виртуальные ф-ии - вот это меняется каждый день.

API либы меняется каждый день? O_O Ну тогда ой.

Use Java, luke. Use C#, luke. Use LISP, luke. Use Haskell, luke. Use Python, luke. Use Ruby, luke.

> Без обид, но ты вообще Си++ или Си знаешь?
Си - на уровне "прочитал K&R" и попробовал написать несколько относительно небольших программ. С++ - честно, нет. Только начинаю осваивать.

>>> Если ты приглядишься, то увидишь ровно те же ограничения в Си.

>> Демагогия.

>Реальность. Добавь поле в Си-структуру - получи несовместимый ABI. Измени сигнатуру - получи то же самое.

Во-первых в Си можно клиенту кода завершенное определение структуры и не давать. Во-вторых сигнатуру можно и не менять, можно написать новую функцию и объявить старую функцию как deprecated. В третьих код на Си собирается в несколько раз быстрее, и потребность в ABI "для себя одного" снижена. В-четвертых я могу часами работать с Си-кодом не проверяя его работоспособность. Про Си++ я такое не могу сказать - приходится делать бранч какой-то подсистемы, отлаживать ее объектную модель, а потом мержить.

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

>А виндовые DLL тоже этим страдают? Или я не очень это понимаю? :-)

Там либо extern "C" либо MS Reflection кторый называется COM.

> Вы хотя бы представляете себе, что это за трудозатраты - создавать сишный интерфейс для с++-х библиотек? В человеко-днях? Это надо взять GObject, да?

Зачем GObject? Бери сразу CORBA. Или SOAP.

> ...Use C#, luke. Use LISP, luke. Use Haskell, luke. Use Python,
> luke. Use Ruby, luke.

А легко ли, используя эти языки, делать GUI в программах? В смысле - если я использую C++, то я без вопросов могу использовать QT. А тут?

> Это надо взять GObject, да?

В фтопку гобджект, проблема надумана.

> Use Java, luke. Use C#, luke. Use LISP, luke. Use Haskell, luke. Use Python, luke. Use Ruby, luke.

Умею использовать Яву и Питон. Постоянно пользуюсь Питоном :)

> А виндовые DLL тоже этим страдают?

у-гу

> А легко ли, используя эти языки, делать GUI в программах?

В Питоне - легко.

> ли я использую C++, то я без вопросов могу использовать QT. А тут?

PyQt, PyGtk.

>А легко ли, используя эти языки, делать GUI в программах?

Гуй все равно на чем делать. Тебе похоже пистон нужен. )

>А легко ли, используя эти языки, делать GUI в программах? В смысле - если я использую C++, то я без вопросов могу использовать QT. А тут?

Из любого из этих языков легко можно использовать gtk, qt например из python'а можно...

две страницы, а гика все нет

> Из любого из этих языков легко можно использовать gtk, qt например
> из python'а можно...

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

> Хохо. Редко нужно менять кол-во полей в структуре. Обычно такое
> случается только во время смены major версии либы. Часто меняются
> структуры в UNIX API?

Тут есть два варианта: добавить поле и убрать поле :-)
Убрать - да, это криминал. А тихонько добавить - разве преступление? :-)

>А чего там у нас с Itanium C++ ABI :?

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

В Си++ тоже

> Во-вторых сигнатуру можно и не менять, можно написать новую функцию и объявить старую функцию как deprecated.

Для функций этот трюк проходит и в Си++. С виртуальными методами классов - да, проблема.

> В третьих код на Си собирается в несколько раз быстрее, и потребность в ABI "для себя одного" снижена

Бгг.

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

Многабукав. Ниасилил.

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

А я больше часа вряд ли смогу. Написал-проверил, написал-отладил. А то потом глюков непонятного происхождения не оберёшься :-)
segfault рано или поздно всё равно будет, и лучше примерно знать, где он появился :-)

Use core, Luke! )

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

>В Си++ тоже

Ложь.

>> Во-вторых сигнатуру можно и не менять, можно написать новую функцию и объявить старую функцию как deprecated.

>Для функций этот трюк проходит и в Си++. С виртуальными методами классов - да, проблема.

Невиртуальные функции в классах ненужны. Зачем тогда классы?

>> В третьих код на Си собирается в несколько раз быстрее, и потребность в ABI "для себя одного" снижена

>Бгг.

Гбб.

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

>Многабукав. Ниасилил.

Ложь + Виляния. Ты отлично знаешь что работоспособность Си-кода можно оценить на глаз если написано чисто. С++ - нельзя. И компилируемость на глаз оценить нельзя.

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

Куча проблем возникает при использовании С++ откуда угодно. Поэтому для GTK гораздо больше биндингов. FFI для C везде есть.

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

Так можно отбить всё желание освоить С++ :-)
Почему-то все на нём пишут, но все говорят, какой он плохой...
Или не все пишут? Ж:-)

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

4.2

>Почему-то все на нём пишут, но все говорят, какой он плохой...

Да, он не идеален. Только вот почему-то товарищи "ниасилившие" не могут понять, что не существует идеальных не игрушечных языков.

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

> Так можно отбить всё желание освоить С++ :-)

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

Re^2: C++ не годится для рогаликов?

Сходи топиком выше, а то там сторонники stdio.h всасывают похлеще пылесоса.

> не существует идеальных не игрушечных языков.
Это в сторону Паскаля про игрушки?

>Есть много более перспективных языков - от Явы до F#.

Могу ошибаться, но мне кажется, что С++ и Ява немного перпендикулярны в смысле областей применения (к Ф# вероятно тоже относится).

>Освой Си, дальше - по вкусу.

Эт да. )

> Освой Си, дальше - по вкусу.
То есть Си, Си++, дальше по вкусу - формула необязательная?

Re^2: C++ не годится для рогаликов?

> Ложь + Виляния. Ты отлично знаешь что работоспособность Си-кода можно оценить на глаз если написано чисто. С++ - нельзя. И компилируемость на глаз оценить нельзя.

Так что там с макросом MAX?

>segfault рано или поздно всё равно будет

>Use core, Luke! )

Упал пад стол)))

К месту сказано +10

Re^2: C++ не годится для рогаликов?

> Куча проблем возникает при использовании С++ откуда угодно. Поэтому для GTK гораздо больше биндингов. FFI для C везде есть.

Для tk биндингов больше. И чо?

Re^4: Кусочек Сахару Троллям ☺

>> есть в C++, но нет в C.

> Работа со строками.

Если ты постоянно работаешь со строками, то тебе путь в перл/тикль, а не в ц. Это раз.

Второе: За счёт применения char* вместо std::string можно офигительно снизить количество ненужных аллокаций и копирований.

>Это в сторону Паскаля про игрушки?

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