существует ли стабильный ABI для Qt?

Для Qt только С++ и полностью удобен.

QtScript?

точнее, его уже вроде банят, QJSEngine из QML за него.

Шутишь шоле? Это же плюсплюс

Казалось бы, причем тут ABI?

Казалось бы, причем тут ABI

При том, что для любой нормальной библиотеки я могу взять символ из .so (или .dll) и выполнить функцию. Для этого достаточно знать документацию на функцию.

Например на Python:

libc = CDLL("libc.so.6")
print libc.time(None)

А для Qt при каждой компиляции имена создаются как компилятору захочется.

для любой нормальной библиотеки я могу взять символ из .so (или .dll) и выполнить функцию

...если она написана на Си

А для Qt при каждой компиляции имена создаются как компилятору захочется

Неужели? А я-то думал, что манглинг и соглашение о вызовах стандартизированы.

Да, у Qt есть ABI. И нет, он тебе не поможет.

Неужели? А я-то думал, что манглинг и соглашение о вызовах стандартизированы.

Да ты норкоман, это 100%

В В Qt куча goto (комментарий) мне пытались доказать, что Qt во всём лучше, чем GTK.

Соответственно пытаюсь уточнить, как с биндингами к другим языкам. Если «Qt лучше, чем Gtk, если писать на C++», то с этим я даже спорить не буду. Но С++ мир не ограничивается.

Кстати, cast wota, Pavval

http://en.wikipedia.org/wiki/List_of_language_bindings_for_Qt_4

если она написана на Си

Не обязательно. На любом языке с документированным ABI. Например, можно написать на OCaml: http://www.camlcity.org/knowledge/kb_002_shared_library.html

А для Qt при каждой компиляции имена создаются как компилятору захочется.

удивительно, как же тогда я собираюсь clang против Qt 5.2.1, а программа запускается с системным Qt 5.0.2, который собран gcc...

«Когда же с ЛОРа идиотов уберут...» (ц)

Хоть ты иди в модераторы и неси в массы разум.

Вопрос появился именно после просмотра указанного списка.

Может у них линкер общий. Попробуй собрать под виндой MSVC и использовать из gcc.

если она написана на Си

Не обязательно

Ну мне-то не рассказывай...

Например, можно написать на OCaml

Это значит, что Ocaml умеет в тот же ABI, что и Си.

На любом языке с документированным ABI

C++ ABI документирован.

А я-то думал, что манглинг и соглашение о вызовах стандартизированы.

где?

Потому что шланг копирует поведение gcc для совместимости

C++ ABI документирован.

Ололо! Может ещё покажешь такой документ

Соглашения о вызовах стандартизованы, а вот манглинг имен в С++, к сожалению, нет.

А я-то думал, что манглинг и соглашение о вызовах стандартизированы.

где?

Окей, я поработаю гуглом: http://mentorembedded.github.io/cxx-abi/abi.html

Соглашения о вызовах стандартизованы, а вот манглинг имен в С++, к сожалению, нет.

5.1 External Names (a.k.a. Mangling)

Ну это вроде не стандарт.

Попробуй собрать под виндой MSVC и использовать из gcc.

а там проблема совсем не в ABI будет (есть волшебный параметр), MSVC и mingw используют разные стандартные библиотеки

При том, что для любой нормальной библиотеки я могу взять символ из .so (или .dll) и выполнить функцию. Для этого достаточно знать документацию на функцию.

Так и есть.

А для Qt при каждой компиляции имена создаются как компилятору захочется.

4.2 Иначе это не библиотеки, а какие-то двоичные файлы.

У библиотек есть экспортированные функции. Запусти nm и убедись Вот, что показывает mc с его помощью (вроде):

                U _Unwind_Resume
                 U qFlagLocation(char const*)
                 U qt_message_output(QtMsgType, char const*)
                 U qFree(void*)
                 U qstrcmp(QByteArray const&, QByteArray const&)
                 U qWarning(char const*, ...)
000000000000b36e W qWarning()
                 U qCritical(char const*, ...)
000000000000ee0f W qCritical()
                 U qt_assert(char const*, char const*, int)
                 U operator delete(void*)
                 U QByteArray::shared_null
000000000000ae5a W QByteArray::data()
                 U QByteArray::clear()
                 U QByteArray::append(char const*, int)
                 U QByteArray::remove(int, int)
                 U QByteArray::realloc(int)
                 U QByteArray::operator=(char const*)
                 U QByteArray::operator=(QByteArray const&)

Ну еще Python таки более менее удобен, остальное думаю не очень. А так, GTK бы тоже могла быть норм, если бы не разработчики. Которые даже оформление каждый релиз ломают.

Вопрос появился именно после просмотра указанного списка.

ну, к примеру, IDE для FPC - Lazarus имеет морду как раз на Qt, насчет PyQt педивикия пишет:

«Среди коммерческих пользователей PyQt можно отметить такие известные корпорации, как Disney, Dreamworks, Pixar, Industrial Light and Magic и Sony Pictures»

а есть еще PySide, например, не ручаюсь, что для всех ЯП есть такие примеры, но Qt используется не только в С++

Тогда надо nm -D (или objdump -T)

Ну это вроде не стандарт.

Это Itanium C++ ABI, доделанный и для 32-битовых архитектур.

Боюсь тебя разочаровать, но тут явно выхлоп nm -D -C.

мог бы просто сказать: «на итаниуме»

А кто его поддерживает? Дело в том, что в стандарте как не было, так и нет.

мог бы просто сказать: «на итаниуме»

Зачем мне это говорить?

In general, this document is written as a generic specification, to be usable by C++ implementations on a variety of architectures. However, it does contain processor-specific material for the Itanium 64-bit ABI, identified as such. Where structured data layout is described, we generally assume Itanium psABI member sizes. An implementation for a 32-bit ABI would typically just change the sizes of members as appropriate (i.e. pointers and long ints would become 32 bits), but sometimes an order change would be required for compactness, and we note more substantive changes.

generic specification, to be usable by C++ implementations on a variety of architectures

Что непонятно?

А кто его поддерживает?

Все Си++-компиляторы для Linux.

Дело в том, что в стандарте как не было, так и нет.

В стандарте Си++? Ну так в стандарте Си тоже нет ABI.

Я правильно понял, что взяли просто gcc-шные правила и назвали это „правилами“? Я бы не стал говорить, что он не лишён недостатков. Например, очевидно, что для более скорого поиска в таблице имён в имени символа надо первыми ставить имена методов, потом классов, а потом пространств имён, а не наоборот.

Я правильно понял, что взяли просто gcc-шные правила и назвали это „правилами“?

Нет. ЕМНИП, Itanium C++ ABI, на основании которого был сделан GCC C++ ABI, был разработан Intel в рамках Monterey или чего-то такого.

Я бы не стал говорить, что он не лишён недостатков

Я думаю, что в рамках дискуссии это неважно. Стандарт есть, но он по очевидным причинам не поможет решить задачу «по-быстрому дернуть Qt».

ок, спасибо за ифну.

Ну для linux договорились и хорошо. Но это не считается общим стандартом, как в случае с теми же вызовами.

Но это не считается общим стандартом

Общим между чем и чем? ABI по определению зависит от платформы. Кстати, в старые времена на венде было 2 «стандарта» для Си++ ABI - от Microsoft и от Borland.

Я говорю исключительно про манглинг имен. Давно можно было договориться и занести это в стандарт языка.

Я говорю исключительно про манглинг имен.

Это всего лишь одна из проблем. Самая простая.

Кстати, в старые времена на венде было 2 «стандарта» для Си++ ABI - от Microsoft и от Borland.

Разве приложения, написанные в Borland не могли дергать нужные функции из библиотек MS VS? И обратно?

Разве приложения, написанные в Borland не могли дергать нужные функции из библиотек MS VS?

Я не помню, как было дело с Си, но библиотеки Си++ были несовместимы.

Общим между чем и чем?

Между поддерживаемыми Qt платформами очевидно. Иначе какая же это кроссплатформенность, если его использовать можно только из одного языка.

Общим между чем и чем?

Между поддерживаемыми Qt платформами очевидно

какая же это кроссплатформенность, если его использовать можно только из одного языка

Что в твоем понимании «платформа»?

Не имеет значение ее сложность. :)

Я не согласился с твоим высказыванием про стандартизованный манглинг, он по сути не стандартизован для всего С++, есть какие-то договоренности на некоторых платформах, да и только.

IDE для FPC - Lazarus имеет морду как раз на Qt

Я тут мимокрокодил, но морда у лазаруса написана на лазарусе и может компилироваться в любой поддерживаемый лазарусом тулкит. Дефолтом для линукса является gtk2, для винды win32/64 etc.

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

и таки имеет морду на Qt - все верно сказано, а насчет дефолта - у меня в репах есть два варианта - qt и gtk

Что в твоем понимании «платформа»

Мне кидали вот это:

http://www.wikivs.com/wiki/GTK_vs_Qt#Portability

Вот и интересно, с точки зрения доступа из Perl/Ruby/Racket/... выигрываю ли я что-либо по сравнению с Gtk? Или только проигрываю (из-за костылей большего размера на windows)?

Что в твоем понимании «платформа»

Мне кидали вот это:
http://www.wikivs.com/wiki/GTK_vs_Qt#Portability

Там под «платформой» подразумевается ОС; в таком случае ABI разный в пределах одной платформы (т.к. он зависит от архитектуры). Зачем ты приплел «кроссплатформенность» в претензию:

monk> какая же это кроссплатформенность, если его использовать можно только из одного языка

я просто не понимаю.

Вот и интересно, с точки зрения доступа из Perl/Ruby/Racket/... выигрываю ли я что-либо по сравнению с Gtk?

Нет. Правда, это не имеет отношения к факту существования Qt ABI. Для использования библиотеки нужны биндинги, а сделать их для Qt - дело сложное, потому что сама библиотека сложная и потому что Си++.

Для использования библиотеки нужны биндинги, а сделать их для Qt - дело сложное,

На самом деле не очень сложное (не сложнее, чем написать привязку к GObjectIntrospection). Есть QMetaClass — значит можно единообразно сгенерировать (или динамически формировать вызовы) ко всем полям и методам. https://github.com/ryanmelt/qtbindings/blob/master/lib/Qt/qtruby4.rb — 3200 строк на Ruby.

Основная проблема — отсутствие стандартного C API к этому метаклассу. Из-за чего каждый городит свой велосипед типа https://github.com/ryanmelt/qtbindings/tree/master/ext/ruby/qtruby/src — ещё более 4000 строк на С++, причём в зависимостях для биндинга тут же появляется gcc + куча заголовочных файлов, что сводит на нет удобство использования такого биндинга за пределами Линукса.