> несовместимости компиляторов нет, если есть исходники, т.е. все можно собрать одним компилятором

А как же знаменитая опенсорсная свобода выбора?

> Это ты почитай LSB, там все описано, вплоть до mangled имен функций из Qt

Как связан *L*SB с компиляторами? Разных компиляторов не две и даже не три штуки. И на линуксе свет клином не сошёлся и этого никогда не произойдёт.

> 4.2, ибо calling convention у DLL от BC и MSCV различаются, и для совместимости нужно в опциях указывать stdcall _явно_, учим матчасть вообщем

Я знаю матчасть и именно это и говорил. Можно спокойно вызвать функцию на Си, ты даже сам сказал как. Для C++ подобной магии не придумали. Calling convention - это не проблема.

> У линукса есть LSB, а все остальное никого не волнует

Для разработчиков компиляторов LSB - это не более чем филькина грамота.

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

Да никто и не сомневался =).

> Но с другой стороны, если символы не лезут в wchar_t, то с ними и сделать ничего нельзя (на экран не вывести стандартными средствами)

Как это нельзя? Если utf-8 локаль, то можно.

>А как же знаменитая опенсорсная свобода выбора?

У тебя есть выбор каким одним компилятором собирать.

Буквально это означает следующее. Выделяем память с помощью new в одном модуле. Затем пытаемся удалить этот же кусок памяти в другом модуле. Какой делокатор будет использован? От первого модуля или от второго?

> Как это нельзя? Если utf-8 локаль, то можно.

В венде локаль utf8?! Если даже установить с помощью setlocale utf8, то всё равно строки будут преобразованы в "родное" для winapi представление - ucs-2.

Хуже того. Есть два модуля. По какой-то причине их собрали разными версиями _одного_ компилятора. Но проблема в том, что в следующей версии поменяли внутреннее представление exception. Как тогда exception будет мигрировать между модулями, которые, напомню, собраны разными версиями компилятора?

>А как же знаменитая опенсорсная свобода выбора?

выбирай: gcc или геморрой =)

>Как связан *L*SB с компиляторами? Разных компиляторов не две и даже не три штуки.

Я знаю только один свободный и самый распространенный, остальные пусть подстраиваются под него, зоопарк abi не нужен

>И на линуксе свет клином не сошёлся и этого никогда не произойдёт.

А что - кто-то надеется перенести свои бинарные библиотеки с винды/whatever на линукс и чтобы все cходу заработало? "Ня-ня-ня!" =)

>Можно спокойно вызвать функцию на Си, ты даже сам сказал как. Для C++ подобной магии не придумали. Calling convention - это не проблема.

Если calling convention (задается-то во время компиляции!) не проблема, то и name mangling тоже не проблема

>Буквально это означает следующее. Выделяем память с помощью new в одном модуле. Затем пытаемся удалить этот же кусок памяти в другом модуле. Какой делокатор будет использован? От первого модуля или от второго?

Если ума не хватило собрать два модуля одним компилятором - то да, начинаем гадать на кофейной гуще

> Какой делокатор будет использован? От первого модуля или от второго?

Тот, который в libstdc++?

> Есть два модуля. По какой-то причине их собрали разными версиями _одного_ компилятора. Но проблема в том, что в следующей версии поменяли внутреннее представление exception. Как тогда exception будет мигрировать между модулями, которые, напомню, собраны разными версиями компилятора?

А это разрабы специально нашли себе проблему, или не знали про свитчи, которые указывают версию ABI?

> Если calling convention (задается-то во время компиляции!) не проблема, то и name mangling тоже не проблема

Фокус в том, что если calling convention задаётся во время компиляции, то правила name mangling прибиты к компилятору и обычно не настраиваются вообще.

>Хуже того. Есть два модуля. По какой-то причине их собрали разными версиями _одного_ компилятора. Но проблема в том, что в следующей версии поменяли внутреннее представление exception. Как тогда exception будет мигрировать между модулями, которые, напомню, собраны разными версиями компилятора?

Ядерные сишные модули, собранные разными версиями (4.2 и 4.3, к примеру) gcc тоже несовместимы между собой, и что? Хватить выдумывать всякую херню.

>Фокус в том, что если calling convention задаётся во время компиляции, то правила name mangling прибиты к компилятору и обычно не настраиваются вообще.

ну так собери все одним компилятором, какие проблемы?

> правила name mangling прибиты к компилятору и обычно не настраиваются вообще.

Они задаются ABI, а версия ABI указывается компилятору. Да и сам вариант mangling'а вроде можно было настраивать раньше (когда их было много).

Это прописные, т.е. прописанные в книгах, истины. Я их не выдумывал сам. Просто моя небольшая интерпретация.

Что касается тех же exception. Можно взять тот же самый g++, но задать разные опции компиляции: в одном случае включить поддержку exception; а во втором - нет. Вполне себе реальная ситуация. И тогда возникнет проблема между двумя модулями.

Мой посыл состоит в том, что много таких технических деталей, которые препятствуют тому, что бы API писался на C++.

>Можно взять тот же самый g++, но задать разные опции компиляции: в одном случае включить поддержку exception; а во втором - нет. Вполне себе реальная ситуация. И тогда возникнет проблема между двумя модулями.

Я тоже могу для одной библиотеки задать fastcall (regparm), а для другой cdecl. Вполне себе реальная ситуация. И тогда возникнет проблема между двумя модулями.

>Мой посыл состоит в том, что много таких технических деталей, которые препятствуют тому, что бы API писался на C++.

Целиком и полностью надуманный посыл, основанный на предвзятом отношении к С++.

> Я тоже могу для одной библиотеки задать fastcall (regparm), а для другой cdecl. Вполне себе реальная ситуация. И тогда возникнет проблема между двумя модулями.

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

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

Нет предвзятости. Напротив, даже озабочен прочтением книги Герба Саттера "Решение сложных задач" (в оригинале Exceptional C++ and More Exceptional C++). Пытаюсь лучше понять материал, с которым непосредственно приходится иметь дело по работе.

> Одно дело явно прописать интерфейс в коде (в твоем случае),

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

Да, в C++ много таких параметров. Например, я еще не говорил об RTTI, который тоже может быть разным в пределах разных модулей. Более того, его тоже можно отключить.

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

Хотя если бы си-пи-пишные бинарники были бы стандартизированы и не было такого разброда в опциях... но это трудно себе представить.

Ошибся. Третьим можно назвать COM/Corba, но это как-то не очень смотрится по сравнению с managed кодом

> Склоняюсь к мысли svu: для общесистемного API либо бинарная совместимость на уровне чего-то вроде Си

Тебе же показали, что ABI можно сломать и в Си, причем теми же методами, что и в Си++.

> либо единая виртуальная машина и стандрартизированный байт-код.

Виртуальная машина не нужна. Да и байт-код, в общем, не нужен. Нужен... ABI :D

> Похоже, что третьего еще не придумали :)

Общесистемные стандарты на соглашения о вызовах успешно реализованы еще лет 30 назад.

> Общесистемные стандарты на соглашения о вызовах успешно реализованы еще лет 30 назад.

А где соглашения по обработке exception?

> Тебе же показали, что ABI можно сломать и в Си, причем теми же методами, что и в Си++.

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

Вот, пример из жизни.

Есть библиотека OCCI для Оракула под Солярис. Эта штука скомпилирована с libCstd, т.е. со старой сановской версией STL. Чтобы использовать новую версию STL нужно задать ключик -library=stlport4. Одно условие: нельзя линковать между собой объектники, если они используют разные версии сановской STL... И если ты используешь OCCI, то ты не можешь использовать новую сановскую STL. Ну, что за хрень!

Как можно мечтать о системном API на плюсах, если возникают такие проблемы при использовании библиотек?! Пусть проприетарщина. Без нее никуда.

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

Ну уж извините, что про защиту от дураков в этом месте не подумали =)

>Нет предвзятости. Напротив, даже озабочен прочтением книги Герба Саттера "Решение сложных задач" (в оригинале Exceptional C++ and More Exceptional C++). Пытаюсь лучше понять материал, с которым непосредственно приходится иметь дело по работе.

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

>> Общесистемные стандарты на соглашения о вызовах успешно реализованы еще лет 30 назад.

> А где соглашения по обработке exception?

ВотЪ. В этом корень проблемы - стандарт ABI описывает нечто, существовашее в прошлом. А прогресс идет, и кто-то придумывает вещь, не учтенную стандартом. И это неизбежно, никакая виртуальная машина и байт-код здесь не помогут - только изменение стандарта.

>> Тебе же показали, что ABI можно сломать и в Си, причем теми же методами, что и в Си++.

> Это был высосанный из пальца пример, переходящий грань разумного.

Не более высосанный, чем пример с Си++.

> Есть библиотека OCCI для Оракула под Солярис. Эта штука скомпилирована с libCstd, т.е. со старой сановской версией STL. Чтобы использовать новую версию STL нужно задать ключик -library=stlport4. Одно условие: нельзя линковать между собой объектники, если они используют разные версии сановской STL...

Это критика Сановской STL или Оракула?

>А где соглашения по обработке exception?

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

>Это был высосанный из пальца пример, переходящий грань разумного.

Будто бы компилирование модулей с разными флагами эту грань не переходит.

>А вот, сломать бинарную совместимость в Си-пи-пи при сохранении неприкосновенным исходного кода - проще простого.

Это как бы не проблема языка/API.

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

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

А про книгу зря так. Весьма достойная книга по плюсам. Может быть, одна из лучших.

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

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

>>А где соглашения по обработке exception?

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

Это относится ко всем.

Представим себе такой случай. Программа написана так, что многие вещи в ней deprecated. Тут вышла новая версия g++, которая превращает deprecated в error. Выход один - использовать старый компилятор.

> Будто бы компилирование модулей с разными флагами эту грань не переходит.

Нет. Реальный use case.

>>А вот, сломать бинарную совместимость в Си-пи-пи при сохранении неприкосновенным исходного кода - проще простого.

> Это как бы не проблема языка/API.

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

> С виртуальной машиной проще. По сути нужно стандартизировать только байт-код,

Это настолько далеко не так, что даже спорить не стану :)

>Представим себе такой случай. Программа написана так, что многие вещи в ней deprecated. Тут вышла новая версия g++, которая превращает deprecated в error. Выход один - использовать старый компилятор.

На новых версиях gcc тоже не всё компилируется.

>Нет. Реальный use case.

Скорее реальный abuse case.

>> wireshark, всё xfce (thunar), medit, emacs, gmpd, fbreader, xchat, midori, stardict, sylpheed, claws, xournal, и ещё дохрена...

>Научился шарить по репозиторию? Молодец. Теперь представь, что я не использую все эти достойные программы.

Ну и как, IE, Winamp и KDE удобнее?

>> Теперь представь, что я не использую все эти достойные программы.

> Ну и как, IE, Winamp и KDE удобнее?

Утипути. Иди под^помолись на труп CDE, пока его не кремировали.

> Это настолько далеко не так, что даже спорить не стану :)

Ради бога.

> это сильное утверждение и оно требует не менее сильного подтверждения... с чего Вы это взяли?

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

чёнить аля //далее идёт скорее всего неправильный код, но это только иллюстация мысли

class Test { public: map<int, * Test> Tests; };

Этот Minoru весьма интересный экземпляр. Такое ощущение что перечитался Виталковского толстого тролления про "программиста-сверхчеловека" образца 2001ого, и про мифологическое мега-удобство древних юниксов, и крутость тогдашних юниксойдов. Практически живое ископаемое.

Могу поспорить что он ещё emacs считает идеальной IDE...

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

data Tree a = Tree { branches :: [Tree a], values :: [a] }

ы? Хотя да, я совсем забыл, что ФП - это для позёров и свихнувшихся теоретиков.

> Этот Minoru весьма интересный экземпляр

Дешевый пАзёр :)

> Практически живое ископаемое.

http://www.linux.org.ru/jump-message.jsp?msgid=3541131&cid=3543020

> ФП

я конечно извиняюсь, но я не понимаю Вашего диалекта. Что есть ФП?

>Практически живое ископаемое.

Я в том смысле, что он ископаемый тролль. Времена мифов о юниксах, и постулирующих абстракции сверхчеловеках - давно прошли.

>я конечно извиняюсь, но я не понимаю Вашего диалекта. Что есть ФП?

Функциональное программирование.

> Что есть ФП?

ФаП, ФаП, ФаП конечно же.

> Функциональное программирование

это всё равно не панацея

Re^2: Релиз Qt 4.5 и Qt Creator 1.0

Хм, сделать хреново_лишь_бы_не_так_как_в_де-факто_промышленном_стандарте - даа, великое достижение. Вот уж точно показывает всю глубину велосипедизма OSS - не просто велосипед сделаем, а с квадратными колесами! Фигня, что ездить неудобно, зато не как у презренных коммерсов, с их великами с круглыми колесами

//Был бы у меня год абсолютно свободного времени - потратил бы на портирование gimp на Qt4. С прикручиванием нормального интерфейса, которым пользоваться можно, а не матом со всех сторон обкладывать. Только вот нет этого времени, нету...

> Хм, сделать хреново_лишь_бы_не_так_как_в_де-факто_промышленном_стандарте

Интерфейс GIMPа непривычен не из-за стремления сделать не так, как у всех. Для этой задачи интерфейс GIMP'а не менее удобен, если привыкнуть. То же касается и Blender'а.

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

Тред сдох

А был бы эпиктред... ЛОР уже не торт

>Кто-нибудь может понятно объяснить, зачем GTK использует чистый C без плюсов?

Потому что чистый С является родным языком для linux...

>Зачем изобретать свое решение, если есть уже проверенное?

Чистый С - является ещё более проверенным решением. :)

>Но QT, STL, MFC используют синтаксис один (плюсовый)

Это Вам так кажется. :) Модели разные.

>Итак, кто-нибудь знает, зачем создатели GTK воспользовались чистым C вместо C++ и какие они из этого получили выгоды?

Когда пишешь на том что хорошо знаешь - это лучшая выгода. Имхо так. :)

>Есть проблемы по-сложнее. Свой внутренний формат для exception, формат для низко-уровневого представления объектов, для управления памятью с помощью new/delete в пределах нескольких модулей и др.

А зачем Вам создавать объект в одном объекте, а удалять в другом? Скорее всего если у Вас встречается такая ситуация - Ваша программа неправильно спроектирована. :)

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

Ваша правда. Однако там есть свои проблемы. :)

Прочитайте например про setjump/sigsetjump и longjump/siglongjump... и про то в чём различие между ними. :)

>Другими словами, у Си++ нет стандарта на реализацию базовых вещей.

Из Ваших слов это никак не следует :)

А вообще для развития - читайте Мейерса, Александреску и пр. У Вас, уверен, сложится более полное впечатление о языке.

>для того, чтобы new/delete работал в пределах нескольких модулей

Ещё раз - это ошибка проектирования!

>Выделяем память с помощью new в одном модуле. Затем пытаемся удалить этот же кусок памяти в другом модуле.

Я конечно не оригинален - но это ошибка проектирования. :)

>Как тогда exception будет мигрировать между модулями, которые, напомню, собраны разными версиями компилятора?

Читайте стандарты - это снова ошибка проектирования...