Да на ядре 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 — это тоже не очень то нужно. Ибо там все по другому и таких проблемм не возникнет :-) берешь и спрашиваешь у класса:«а скажи ка мне тварищь, а есть ли у тебя метод „а“? Если есть то дерни ка мне его с вот таким вот списком параметров.Если нету то добавь ка его с вот такой реализацией и дерни его с вот таким вот списком параметров :-) ».
это встраиваемые системы. Можно засунуть туда СТЛ, но в нашем случае он там не нужен.Там и так счет идет не на мегабайты а на сотни килобайт. Сто килобайт плюс — уже нужны внятные пояснения почему.
Спасибо за критику. Первые два пункта абсолютно согласен.
Вот третий — блог посвящен Qt, речь идет об внутренностях и подходах Qt и речь идет именно о чисто Qt-style подходу реализации этого паттерна. Речь идет о паттерне Pimpl d-pointer. Ввиду вышеуказанных обстоятельств можно предположить что это все касается исключительно C++ или гибридных языков, или языков которые в себя могут включать C++ (например тот же самый Objective-C).
По поводу php — я даже не знаю зачем этот паттерн там вообще нужен :-). Может потому-что я в php не силен, а может потому-что он там действительно не нужен. Интерпретатор и ABI вещи не совместимые :-)
естественно в гуи в качестве дергания свойства в ответ на реакцию нажатия — это очень гут.
А вот использовать свойства для выполнения сортировке на милионном массиве данных — не очень хорошо :-)
Всему есть свое место применения :-) Для этого думалка и нужна :-)
По поводу примера использования?
ну вот давайте на примере Qt рассмотрим.
Ребята разрабатывают библиотку или фреймворк (вернее набор библиотек, в мак ос для этого есть термин — «зонтик», а вот остальные не позаботились :-) ). Буду называть ее как одну библиотеку, пусть даже модульную.
И так они выплевывают релиз 4.0.0 — все дружно начинают присать свои приложения для него и динамически с ним линкуются. Тут выходит библиотека 4.0.1 и баз все приложения которые были собраны с предыдущей версией просто тупо падают, сегментятса или просто отказываются запускатся. В этом случае прийдется пересобирать абсолютно все приложения использующие эту библиотеку, чтобы перелинковать.
Это типо общее описание проблеммы. Qt одни из первых, кто в своих библиотеках обзаботился об ABI. Они гарантируют что все приложения собраные с любой из 4 версией библиотеку будут работать с любой другой библиотекой версии 4. Тоесть я собрал с Qt 4.6 а работать она будет с 4.1 (правда лишь в том случае, если вы не используете новые возможности, которых нет в 4.1. Но даже в этом случае можно разрулить ситуацию програмно, в Qt есть макросы чтобы узнать какой версии библиотеки сейчас в рантайме и либо сообщить юзеру что они сильно старые либо решить ту же задачу но менее оптимальным путем через другую реализацию).
Вот Pimpl для этого и нужен. Что по поводу второй части вопроса. Да конечный машинный код библиотеки изменится, но!!! ABI публичного класса останется тот же. Изменится ABI приватного, но вы же линковались с ABI публичным. Так что все нормально.
Вообще так если кратко, в любой программе (библиотека как один из вариантов) есть два интерфейса — API и ABI. Ну что такое API я думаю объяснять нет необходимости. Это функции с параметрами, переменные и тд. API используется в «Design Time» — при написании кода, а ABI в «Run Time». ABI позволяет ОС правильно запускать приложения и библиотеки и он зависит от ОС (Windows, Linux ...), архитектуры ( I386, PPC, SPARC) и от конкретной реализации (в линукс например есть две популярные реализации загрузчика — Elf и a.out, ABI у них разный). Все сказаное выше очень упрощено, в действительности все немножечко не так :-)
Ну вот начал писать и оказалось что мыслей так много что необходимо выместить их в отдельной статье.
Это значит что публичный интерфейс у нас всегда в публичном классе а свойства объекта и логика в приватном. Это можно назвать функциоанльной структуризацией. А так как у нас этих классов целая иерархия то получаем целый комплекс, который построен по общему принципу — Pimpl. Да выражение действительно у меня получилось непонятным. Подумаю как сказать проще.
Есть плюсы, есть минусы. Как минимум виджеты должны иметь их для того чтобы можно было реализовать плагин для дезайнера и для получения метаинформации из объекта.
Тка что в некоторых случаях это необходимо, но в некоторых избыточно. Как минимум это увеличивает скорость доступа к свойствам.
Если тема интересана — то попробую осветить ее поподробней.
да и плюс многие кто переходит с С++ на кьют (у нас в конторе это все «новенькие» :-) ибо на рынке труда практически нет кьют специалистов) начинают выдумывать велосипеды :-) А был один смешной кадр, он вообще заявил «без буста кодить нельзя», а когда я ему сказал что у нас на таргет платформы СТЛя нету, он был ошарашен и не мог понят как же ему теперь писать код :-) Ну в догонку можно сказать что было у него еще заявление такого рода «const — это балавство», после того как я у него поинтересовался, почему же он нехороший человек поубирал const из методов. Типа не собиралось у него :-)
хм. Вариант кстати. А если его сделать шаред. то вообще можно получить самоудаляемый синглетон.
Нада подумать на эту тему. Для малоресурсных систем достаточно актуально.
Типа не нуждается в нем никто — с глаз долой из памяти вон! :-)
Сделаю брейншторм на эту тему, может хорошый подпаттерн появится :-)
Вот тут не очень понимаю? какое преимущество в реализации синглетонов это дает?
Вот в implicit sharing например понятно: создаем копию текущего класса, а в качестве приватного берем указатель (вернее шаред указатель) на экземпляр того от которого копируемся, и держим до тех пор, пока не был вызван метод модификации, вот тогда происходит реальное копирование. Вот тут «кота» в руки, так сказать. А вот как с синглетону это поможет?
Вот по поводу 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 очень простой — дописал пару макросов и сделал дополнительный хедер (не обязательно).
Вот третий — блог посвящен Qt, речь идет об внутренностях и подходах Qt и речь идет именно о чисто Qt-style подходу реализации этого паттерна. Речь идет о паттерне Pimpl d-pointer. Ввиду вышеуказанных обстоятельств можно предположить что это все касается исключительно C++ или гибридных языков, или языков которые в себя могут включать C++ (например тот же самый Objective-C).
По поводу php — я даже не знаю зачем этот паттерн там вообще нужен :-). Может потому-что я в php не силен, а может потому-что он там действительно не нужен. Интерпретатор и ABI вещи не совместимые :-)
А вот использовать свойства для выполнения сортировке на милионном массиве данных — не очень хорошо :-)
Всему есть свое место применения :-) Для этого думалка и нужна :-)
ну вот давайте на примере Qt рассмотрим.
Ребята разрабатывают библиотку или фреймворк (вернее набор библиотек, в мак ос для этого есть термин — «зонтик», а вот остальные не позаботились :-) ). Буду называть ее как одну библиотеку, пусть даже модульную.
И так они выплевывают релиз 4.0.0 — все дружно начинают присать свои приложения для него и динамически с ним линкуются. Тут выходит библиотека 4.0.1 и баз все приложения которые были собраны с предыдущей версией просто тупо падают, сегментятса или просто отказываются запускатся. В этом случае прийдется пересобирать абсолютно все приложения использующие эту библиотеку, чтобы перелинковать.
Это типо общее описание проблеммы. Qt одни из первых, кто в своих библиотеках обзаботился об ABI. Они гарантируют что все приложения собраные с любой из 4 версией библиотеку будут работать с любой другой библиотекой версии 4. Тоесть я собрал с Qt 4.6 а работать она будет с 4.1 (правда лишь в том случае, если вы не используете новые возможности, которых нет в 4.1. Но даже в этом случае можно разрулить ситуацию програмно, в Qt есть макросы чтобы узнать какой версии библиотеки сейчас в рантайме и либо сообщить юзеру что они сильно старые либо решить ту же задачу но менее оптимальным путем через другую реализацию).
Вот Pimpl для этого и нужен. Что по поводу второй части вопроса. Да конечный машинный код библиотеки изменится, но!!! ABI публичного класса останется тот же. Изменится ABI приватного, но вы же линковались с ABI публичным. Так что все нормально.
Вообще так если кратко, в любой программе (библиотека как один из вариантов) есть два интерфейса — API и ABI. Ну что такое API я думаю объяснять нет необходимости. Это функции с параметрами, переменные и тд. API используется в «Design Time» — при написании кода, а ABI в «Run Time». ABI позволяет ОС правильно запускать приложения и библиотеки и он зависит от ОС (Windows, Linux ...), архитектуры ( I386, PPC, SPARC) и от конкретной реализации (в линукс например есть две популярные реализации загрузчика — Elf и a.out, ABI у них разный). Все сказаное выше очень упрощено, в действительности все немножечко не так :-)
Ну вот начал писать и оказалось что мыслей так много что необходимо выместить их в отдельной статье.
doc.trolltech.com/qq/qq13-apis.html вот от бывшего троллтека документация официальня :-)
Тка что в некоторых случаях это необходимо, но в некоторых избыточно. Как минимум это увеличивает скорость доступа к свойствам.
Если тема интересана — то попробую осветить ее поподробней.
Нада подумать на эту тему. Для малоресурсных систем достаточно актуально.
Типа не нуждается в нем никто — с глаз долой из памяти вон! :-)
Сделаю брейншторм на эту тему, может хорошый подпаттерн появится :-)
Вот в implicit sharing например понятно: создаем копию текущего класса, а в качестве приватного берем указатель (вернее шаред указатель) на экземпляр того от которого копируемся, и держим до тех пор, пока не был вызван метод модификации, вот тогда происходит реальное копирование. Вот тут «кота» в руки, так сказать. А вот как с синглетону это поможет?
По поводу Q_Q — смотри пункт 9 — там он описан (Q-указатель (он же Q-pointer)).