this не обязательно идет первым — не забывайте что есть little endian и big endian архитектуры. Но это так к слову. Теперь по сути.
ABI не только calling conversion. Естественно, если интерфейс менятся не будет, а будет менятся только код в cpp файле — то все будет очень хорошо. Имейте ввиду что это не относится к коду, который находится в заголовочном файле. Кстати одна из причин почему не нужно писать его в заголовочном файле, даже если он пустой, потому как надумаете наконец его реализовать, то потеряете эту злощастную бинарную совместимость.
Если вы допустим добавите виртуальный метод в класс и поставите его на первом месте — то виртуальные адреса всех других методов сдвинутся и ваш код, который был слинкован попадет уже в другое место. Если же вы добавите виртуальный метод после всех остальный, то все будет хорошо.
Pimpl — это не панацея и не единственный вариант сохранить бинарную совместимость, я уже приводил ссылку на KDE TechBase где рассказывается что можно делать и останется бинарная совместимость и в каких случаях она поломается. Вот эта статья: techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++#The_Do.27s_and_Don.27ts
Я планируя посвятить этому тему. Так как это необходимо знать каждому, кто разрабатывает библиотеки для «общего пользования». И расскажу подробней обо всех ньюансах.
Часто встречаются проблеммы с бинарной совместимостью. Как пример — Qt на линукс в бинарниках идет без поддержки Phonon, потому что ни GStreamer ни Xine (которые сейчас поддерживаются как бэкэнды) не заботятся о бинарной совместимости. Поэтому необходимо кути собирать непосредственно с теми библиотеками, которые стоят именно на вашем компьютере. А самое интересно начинается когда вы собираетесь поставлять свою программу со своими кастомными библиотеками Qt на Linux — тут уже наступает «ахтунг», либо тянуть GStreamer с собой или Xine. Либо в качестве зависимостей тянуть девелоперские пакеты для одной из этих библиотек и собирать фонон уже в скрипте при установке либо требовать чтобы пользователь об этом позаботился сам ну или использовать системный фонон и прописать его в зависимости. Все варианты не очень. И все из-за того что кто-то не позаботился о бинарной совместимости. Хотя я слышал что и Xine и GStreaner пообещали впредь относится серьезней и далее ситуация должна изменится.
Проблемма бинарной совместимости есть и ее просто необходимо знать, но увы очень мало документации по этой теме. Так что я собираюсь пятую статью посвятить именно этому вопросу.
достаточно неприметная небольшая компания SmartLabs (http://smartlabs.tv). Кстати есть один продукт популярный, который мой коллега написал — TsMuxeR называется. Служит для пересборки контейнеров для видео. Тоесть по факту можно из ts файла получить mpeg4 обычный без длительного перекодирования, либо собрать BlueRay диск. Ну вобщем вроде популярная утилитка.
Вообще мы занимаемся IpTv. Сейчас одну из наших поделок можно увидеть на приставках у StreamTv. Вот если у кого есть — это все сделано как раз на Qt. Причем Амина 110 достаточно старая и там стоит PowerPC 405 процессор с 16 Mb постоянной памяти (NORFLASH) и 32 оперативной. Туда мы вместили наше приложение операционку драйверы и кути и еще кучу поделок. Не могу выдавать тайны а на каком этапе у нас внедрение я не знаю.
да и кстати мой блог постиг хабраэффект :-) так как большинство посещений из России, Украины и Белорусии. Рейтинг идет в этом порядке, только между Россией и Украиной стоит США (сначала написал а потом понял двойственный смысл :-))
Так что ребята спасибо за хабраэффект :-) Никогда не верил в разный там интернет пиар а тут увидел его в действии.
Спасибо. Честно говоря я собирался писать только на английском. Но потом захотелось стать частью хабра и решил написать статью в двух вариантах. По английски я пишу чтобы подтянуть свой английский, так как собираюсь сдавать IELTS экзамены. Одно из модулей сдачи — написание сочинения. Вот и тренируюсь. Плюс действительно действенно так как приходится вспоминать времена и некоторые слова (точнее часть слов из пассивного словаря переношу в активный).
Но после того как я увидел резонанс (посещаемость моего блога сейчас 400 в день !!!) меня подбило занятся этим на «постоянной основе». Тем более, что рассказать мне еще много чего есть и я лично очень болею за будущее Qt и в моих же интересах вложить свои 5 копеек в популяризацию этого фреймворка. В этом случае востребованость Qt специалистов выростет, чему буду я очень рад :-)
Да кстати кому интересно. Я сейчас тут переписываюсь с Андре Поэтисом, который занимается разработкой Qt-creator по поводу gdbmacroshelper. Он поддерживает меня что он реализован не очень. Поэтому они ведут разработку по его улучшению и уже есть девелоперский вариант, который он выложил в репозиторий по моей просьбе. Суть в том, что теперь испльзуется не call команда gdb, а биндинг питоновго скриптинга в gdb.
Моя основная идея состоит в том, чтобы расширить этот механизм для того чтобы можно было создавать дамперы своих кастомных классов. При существующей схеме единственный вариант — это линговать этот макрос с той библиотекой из которой вы хотите дампить класса. Так вот идея состоит в том чтоб придумать как это сделать так, чтобы можно было не прибегая к добавлению лишнего кода в исходники и не делая зависимым gdbmacroshelper от левого кода дать возможность людям писать собственные дамперы как можно проще.
Вот напишу что и как я нарыл чуть позже, может кто посоветует чего-нибудь.
Можно кстати будет потом вывернуть на изнанку moc предкомпилер и добавить возможность обработки собственного препроцессинга через плагины. Вот такая у меня идея вчера перед сном пришла. Правда прийдется систему плагинов делать чисто C++ ибо на момент сборки moc предполагается что qt еще не собран :-) Но это не остановит настоящего индейца.
в бусте есть точно такое же «ключевое слово» (из-за этого при миксе буста и кутишного кода лучше пользоватся Q_SLOTS вместо slots). Кстати про сигналы и слоты тут перевод есть официальной доки в хабре habrahabr.ru/blogs/qt_software/50812/.
Очень полезный механизм, четко спионереный у NextStep'а, GTK+ и boost тоже повзаимствовали его :-)
Ну вообще то Qt не был портирован ни на один из языков. Он существует, существовал и будет существовать только на C++. Что касается QtJambi, PyQt, QT-D, Qt# и им подобных — это биндинг — тоесть привязка. Само же Qt на С++. В большей степени эти биндинги используются как инструменты для этих хост-языков для реализации GUI (отсюда и миф, что Qt — это GUI Framework).
Но для ясности допишу в начале.
Да на ядре 2.4 встречал системы с монопольной поддержкой a.out. Зачем это так сделано — сам удивлялся, но спросить было не с кого. :-)
Вот по поводу LGPL — не знаю, все может быть. Я честно пытался прочитать LGPL, но всякий раз засыпал. Там все так нечетко написано. Нельзя вот было взять и вынести по пунктам очень кратко. Что-то вроде этого:
1. Можно использовать в комерческом ПО.
2. Можно линковать статически и динамически.
3. Можете не выкладывать в общий доступ при изменении кишков.
4…
ну и так далее. То-есть для простых людей а не для юристов там разных. Для юристов пусть отдельный документ будет. Так как они любят — со всякими уточнениями изъянами и защитой от левопроходства :-)
Стл естественно есть. Но он абсолютно не нужен и поддержка его отключена в нашей сборке Qt. лишние 200 кб знаете ли. Мы убрали СТЛ из устройств так как им абсолютно не пользуемся. Не нужен он вообще в нашем случае.
да именно поэтому. Все Qt библиотеке на устройстве у нас весят окол 5 метров.
Есть еще варианты реализовать портируемую платформу для графического интерфейса без Иксов (нереально большой оверхед дают даже TinyX и подобные ему)?
А ну и чтоб это влазило в 5 метров?
С учетом того что один сам по себе libstdc++ весит порядка полутора метров. Я молчу об возможных прослойках (DFb, Microwindows, tinyX) и библиотека виджетов сколько будет весить да и еще чтоб это с пол-тычка портировалось под какую-нибудь архитектуру с ядром 2.4 и процессором от «Дядя Вася Анлимитед». У нас уже наша система портирована под 6 различных платформ, плюс пару эксперементальных. Смею заметить на некоторых платформах используются gcc 2.x.x компиляторы.
Или Вы думаете мы не проводили масштабный ресеч по поводу возможных вариантов? Был рассмотрен вариант даже OpenTV — у них приложение крутится в мультикаст потоке в виде карусели и загружается на клиента по сети по кусочкам (у НТВ на приставках такая штука стоит). Я даже немного покодил на этом кошмаре. Хотя идея просто колосальная.
Я буду очень рад, если предложите вариант лучше.
ЗЫ: Кьют дает нереально большие возможности оптимизации при графической отрисовке в QWS-windows system.
ЗЫЫ: Плюс ко всему мы имеем огромный бонус в виде возможности кодинга и сборки приложения на десктопе и отображение в QVFb — что почти всегда соотвествет действительному результату, за исключением платформо-зависимых багов видео подсистемы на каждом отдельно взятом типе устройств.
Да все обращения происходят через d_ptr. Не вся работа происходит через класс-обвертку. Объем этих работ вы можете устанавливать сами, есть три варианта:
1. Все приватные данные храните в приватном классе — вся логика в публичном классе.
2. Все приватные данные храните в приватном классе — та логика, которая перекрывается в дереве наследования выносится в приватный класс а собственная остается в публичном.
3. Вся логика и данные уносятся в приватный класс. — в основном Qt придерживаются этого подхода.
3 метод используется при обычной схеме разработки ПО, когда сначала проектируют модель, интерфейсы в виде схемы (обычно на UML)и потом на основании этого пишется код. Тоесть какие методы должны быть в публичном классе на момент начала написания кода уже известны. А как это реализовано уже прячется в приватный класс. И изменение этой реализации никак снаружи видно не будет.
В итоге с публичным классом можно делать некоторые изменения. Но очень аккуратно. Допустим добавить в конец виртуальный метод. От этого таблица виртуальных методов не поломается, просто в конец добавится метод.
Вот не понял что имеется ввиду под выражением «стандартный интерфейсный набор функций»
Почему не реализовать через dll или so? потому как ломается ABI. Вам всегда нада иметь публичную библиотеку подходящую под ваши приватные библиотеки. В принципе их можно таскать вместе. Но зачем ??? Тут как раз оверхед достаточно большой получается при подходе использовать пару dll. Pimpl очень простой — дописал пару макросов и сделал дополнительный хедер (не обязательно).
ну вот и я о том. Pimpl по версии Qt интересен там где интерфейс и реализация вынесены в отдельные файлы. Ну кстати вот в Objective-C — это тоже не очень то нужно. Ибо там все по другому и таких проблемм не возникнет :-) берешь и спрашиваешь у класса:«а скажи ка мне тварищь, а есть ли у тебя метод „а“? Если есть то дерни ка мне его с вот таким вот списком параметров.Если нету то добавь ка его с вот такой реализацией и дерни его с вот таким вот списком параметров :-) ».
это встраиваемые системы. Можно засунуть туда СТЛ, но в нашем случае он там не нужен.Там и так счет идет не на мегабайты а на сотни килобайт. Сто килобайт плюс — уже нужны внятные пояснения почему.
ABI не только calling conversion. Естественно, если интерфейс менятся не будет, а будет менятся только код в cpp файле — то все будет очень хорошо. Имейте ввиду что это не относится к коду, который находится в заголовочном файле. Кстати одна из причин почему не нужно писать его в заголовочном файле, даже если он пустой, потому как надумаете наконец его реализовать, то потеряете эту злощастную бинарную совместимость.
Если вы допустим добавите виртуальный метод в класс и поставите его на первом месте — то виртуальные адреса всех других методов сдвинутся и ваш код, который был слинкован попадет уже в другое место. Если же вы добавите виртуальный метод после всех остальный, то все будет хорошо.
Pimpl — это не панацея и не единственный вариант сохранить бинарную совместимость, я уже приводил ссылку на KDE TechBase где рассказывается что можно делать и останется бинарная совместимость и в каких случаях она поломается. Вот эта статья: techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++#The_Do.27s_and_Don.27ts
Я планируя посвятить этому тему. Так как это необходимо знать каждому, кто разрабатывает библиотеки для «общего пользования». И расскажу подробней обо всех ньюансах.
Часто встречаются проблеммы с бинарной совместимостью. Как пример — Qt на линукс в бинарниках идет без поддержки Phonon, потому что ни GStreamer ни Xine (которые сейчас поддерживаются как бэкэнды) не заботятся о бинарной совместимости. Поэтому необходимо кути собирать непосредственно с теми библиотеками, которые стоят именно на вашем компьютере. А самое интересно начинается когда вы собираетесь поставлять свою программу со своими кастомными библиотеками Qt на Linux — тут уже наступает «ахтунг», либо тянуть GStreamer с собой или Xine. Либо в качестве зависимостей тянуть девелоперские пакеты для одной из этих библиотек и собирать фонон уже в скрипте при установке либо требовать чтобы пользователь об этом позаботился сам ну или использовать системный фонон и прописать его в зависимости. Все варианты не очень. И все из-за того что кто-то не позаботился о бинарной совместимости. Хотя я слышал что и Xine и GStreaner пообещали впредь относится серьезней и далее ситуация должна изменится.
Проблемма бинарной совместимости есть и ее просто необходимо знать, но увы очень мало документации по этой теме. Так что я собираюсь пятую статью посвятить именно этому вопросу.
Вообще мы занимаемся IpTv. Сейчас одну из наших поделок можно увидеть на приставках у StreamTv. Вот если у кого есть — это все сделано как раз на Qt. Причем Амина 110 достаточно старая и там стоит PowerPC 405 процессор с 16 Mb постоянной памяти (NORFLASH) и 32 оперативной. Туда мы вместили наше приложение операционку драйверы и кути и еще кучу поделок. Не могу выдавать тайны а на каком этапе у нас внедрение я не знаю.
Так что ребята спасибо за хабраэффект :-) Никогда не верил в разный там интернет пиар а тут увидел его в действии.
Но после того как я увидел резонанс (посещаемость моего блога сейчас 400 в день !!!) меня подбило занятся этим на «постоянной основе». Тем более, что рассказать мне еще много чего есть и я лично очень болею за будущее Qt и в моих же интересах вложить свои 5 копеек в популяризацию этого фреймворка. В этом случае востребованость Qt специалистов выростет, чему буду я очень рад :-)
Моя основная идея состоит в том, чтобы расширить этот механизм для того чтобы можно было создавать дамперы своих кастомных классов. При существующей схеме единственный вариант — это линговать этот макрос с той библиотекой из которой вы хотите дампить класса. Так вот идея состоит в том чтоб придумать как это сделать так, чтобы можно было не прибегая к добавлению лишнего кода в исходники и не делая зависимым gdbmacroshelper от левого кода дать возможность людям писать собственные дамперы как можно проще.
Вот напишу что и как я нарыл чуть позже, может кто посоветует чего-нибудь.
А во вторых так проще парсить в moc.
Очень полезный механизм, четко спионереный у NextStep'а, GTK+ и boost тоже повзаимствовали его :-)
lists.trolltech.com/qt-interest/2007-09/thread00325-0.html
за поправку спасибо.
Но для ясности допишу в начале.
Вот по поводу LGPL — не знаю, все может быть. Я честно пытался прочитать LGPL, но всякий раз засыпал. Там все так нечетко написано. Нельзя вот было взять и вынести по пунктам очень кратко. Что-то вроде этого:
1. Можно использовать в комерческом ПО.
2. Можно линковать статически и динамически.
3. Можете не выкладывать в общий доступ при изменении кишков.
4…
ну и так далее. То-есть для простых людей а не для юристов там разных. Для юристов пусть отдельный документ будет. Так как они любят — со всякими уточнениями изъянами и защитой от левопроходства :-)
Есть еще варианты реализовать портируемую платформу для графического интерфейса без Иксов (нереально большой оверхед дают даже TinyX и подобные ему)?
А ну и чтоб это влазило в 5 метров?
С учетом того что один сам по себе libstdc++ весит порядка полутора метров. Я молчу об возможных прослойках (DFb, Microwindows, tinyX) и библиотека виджетов сколько будет весить да и еще чтоб это с пол-тычка портировалось под какую-нибудь архитектуру с ядром 2.4 и процессором от «Дядя Вася Анлимитед». У нас уже наша система портирована под 6 различных платформ, плюс пару эксперементальных. Смею заметить на некоторых платформах используются gcc 2.x.x компиляторы.
Или Вы думаете мы не проводили масштабный ресеч по поводу возможных вариантов? Был рассмотрен вариант даже OpenTV — у них приложение крутится в мультикаст потоке в виде карусели и загружается на клиента по сети по кусочкам (у НТВ на приставках такая штука стоит). Я даже немного покодил на этом кошмаре. Хотя идея просто колосальная.
Я буду очень рад, если предложите вариант лучше.
ЗЫ: Кьют дает нереально большие возможности оптимизации при графической отрисовке в QWS-windows system.
ЗЫЫ: Плюс ко всему мы имеем огромный бонус в виде возможности кодинга и сборки приложения на десктопе и отображение в QVFb — что почти всегда соотвествет действительному результату, за исключением платформо-зависимых багов видео подсистемы на каждом отдельно взятом типе устройств.
1. Все приватные данные храните в приватном классе — вся логика в публичном классе.
2. Все приватные данные храните в приватном классе — та логика, которая перекрывается в дереве наследования выносится в приватный класс а собственная остается в публичном.
3. Вся логика и данные уносятся в приватный класс. — в основном Qt придерживаются этого подхода.
3 метод используется при обычной схеме разработки ПО, когда сначала проектируют модель, интерфейсы в виде схемы (обычно на UML)и потом на основании этого пишется код. Тоесть какие методы должны быть в публичном классе на момент начала написания кода уже известны. А как это реализовано уже прячется в приватный класс. И изменение этой реализации никак снаружи видно не будет.
В итоге с публичным классом можно делать некоторые изменения. Но очень аккуратно. Допустим добавить в конец виртуальный метод. От этого таблица виртуальных методов не поломается, просто в конец добавится метод.
Вот не понял что имеется ввиду под выражением «стандартный интерфейсный набор функций»
Почему не реализовать через dll или so? потому как ломается ABI. Вам всегда нада иметь публичную библиотеку подходящую под ваши приватные библиотеки. В принципе их можно таскать вместе. Но зачем ??? Тут как раз оверхед достаточно большой получается при подходе использовать пару dll. Pimpl очень простой — дописал пару макросов и сделал дополнительный хедер (не обязательно).