Coding Faq

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

Сразу замечу, что клиент взрослел вместе с нами, и пережил много детских болезней, от которых не везде избавился. Места (а точнее, достаточно часто) он содержит код, от которого мы хотели бы давно избавиться. Есть куча подсистем, которые делают "одно и то же": некоторые более новые и приятные в использование, другие это эксперимент и т.д. Не судите строго.

Велосипеды?

1. Ptr.

   В чем была необходимость в создании так называемых «велосипедов»?
   например: Ptr, аналоги которого присутствует в Qt (QSharedPointer) и boost
   

   • QSharedPointer появился в 4.5. Ptr у нас появилась при версии Qt 4.2
   • QSharedDataPointer даже по описанию в документации не подходит

The QSharedDataPointer class provides a pointer to a shared data object. Опишу более подробно: этот класс предназначен для хранения данных. Мы для этого используем boost::shared_ptr (потому что при этом нет необходимости добавлять наследование). Вообще, обращаясь к документации Qt мы увидим в 4.6 более развитую модель этих указателей. Но она предназначена для разделения данных, а не для хранения интерфейсов

• boost::shared_ptr не подходит из-за невозможности создавать shared_ptr изнутри класса на самого себя при сложной иерархии наследование. Допустим есть класс A, B, и общий потомок С. Хочется, чтоб они все имели возможность подсчета ссылок с общим счетчиков (тут нам в этом поможет виртуальное наследование). Но для того, чтоб можно было создавать изнутри класса shared_ptr на себя, требуется отнаследоваться его от boost::enablead_shared_from_this. С другой стороны, если в иерархи возникнет 2 класса boost::enablead_shared_from_this, то становится не ясно, какой из них будет базой для создания shared_ptr, и, в результате, у нас фактически возникнет несколько счетчиков ссылок. За подробностями прошу в исходники boost::shared_ptr. boost::shared_ptr хорошо подходит при необходимости придать свойства подсчета ссылок снаружи класса (чем я и пользуюсь для простых классов контейнеров данных) . Причина такого поведения в немного другом подходе к типизации объектов в boost (у них мало используются интерфейсы)
• Преимущества: типобезопасность. Вы не можете получить чистый указатель на объект. Не сможете обратить к нулевому указателю - сразу же получите ASSERT, и спуск по стеку (таким образом приложение не когда не упадет при обращении к нулевому указателю). Кроме того, сейчас в ptr я добавляю кучу вспомогательных методов ( alloc, check_cast, cast и тд) - но пока до конца не определился с названием методов и поведением

2. boost

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

Используем: boost::bind, boost::function, boost::lambda, boost::mpl, boost::type_traits, boost::shared_ptr