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

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

class RealClass {
public:
void SomeMethod () {...}
};

class ProxyClass {
boost::shared_ptr<RealClass> m_pImpl;
public:
void SomeMethod () {m_pImpl->SomeMethod ();}
};
 

В этом случае объекты прокси-классов одновременно являются смартпойнтерами - их можно свободно копировать и передавать по значению. Проблема здесь, ИМХО, использование boost::shared_ptr - его структура достаточно нетривиально (в частности, из-за завязок на weak_ptr), поэтому не исключено, что в следующих версиях Буста shared_ptr будет сильно изменен, что приведет к невозможности взаимодействия модулей с разными версиями Буста.

Возможно, более удачным будет такой вариант:

class RealClass {
public:
void SomeMethod () {...}
};

class ProxyClass {
boost::scoped_ptr<RealClass> m_pImpl;
public:
void SomeMethod () {m_pImpl->SomeMethod ();}
};
 

Здесь shared_ptr заменен на scoped_ptr. В результате прокси-класс перестал быть смартпойнтером и стал некопирабельным. Если требуется смартпойнтер, то он может быть создан явно на стороне вызывающего модуля:

typedef boost::shared_ptr<ProxyClass> RealClassPtr;
 

scoped_ptr имеет крайне простую структуру - фактически, это просто класс, хранящий обычный указатель и удаляющий объект в деструкторе. Поэтому, считаю, scoped_ptr вряд ли будет меняться в следующих версиях Буста.

Так же scoped_ptr хорош тем, что он некопирабелен. В этом он имеет преимущество перед std::auto_ptr. В случае auto_ptr у нас появлялись бы некорректные объекты прокси-классов.

Может быть, для построения прокси-классов стоит вообще отказаться от Буста и реализовать некий шаблонный класс, похожий на scoped_ptr.

artbear писал(а) 21. Марта 2008 :: 10:37:

Достаточно их не определять вообще Тогда умолчальные реализации будут обламываться при попытке скопировать m_pImpl. scoped_ptr некопирабельный.

artbear писал(а) 21. Марта 2008 :: 10:37:

Для "полностью независимых" вообще не важно чего мы будет использовать Они же вообще независимы Но мне кажется, что scoped_ptr не будет вообще меняться - потому что менять там уже особо нечего В принципе, можно выдрать его из Буста, запихнуть в отдельный namespace и зафиксировать в SDK. Для scoped_ptr такая операция должна быть простой.

Uzhast писал(а) 21. Марта 2008 :: 09:58:

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