Я думаю , що це погана стратегія , щоб Derived_1::Impl
витягти з Base::Impl
.
Основна мета використання ідіоми Pimpl - приховати деталі реалізації класу. Дозволяючи Derived_1::Impl
виходити Base::Impl
, ви перемогли цю мету. Тепер не тільки Base
залежить Base::Impl
реалізація, Derived_1
залежить також і реалізація Base::Impl
.
Чи є краще рішення?
Це залежить від того, які компроміси для вас прийнятні.
Рішення 1
Зробіть Impl
заняття абсолютно самостійними. Це означає, що до Impl
класів буде два вказівники - один в Base
і інший в Derived_N
.
class Base {
protected:
Base() : pImpl{new Impl()} {}
private:
// It's own Impl class and pointer.
class Impl { };
std::shared_ptr<Impl> pImpl;
};
class Derived_1 final : public Base {
public:
Derived_1() : Base(), pImpl{new Impl()} {}
void func_1() const;
private:
// It's own Impl class and pointer.
class Impl { };
std::shared_ptr<Impl> pImpl;
};
Рішення 2
Виставляйте класи лише як ручки. Не піддавайте визначення класів та їх виконання взагалі.
Загальнодоступний файл заголовка:
struct Handle {unsigned long id;};
struct Derived1_tag {};
struct Derived2_tag {};
Handle constructObject(Derived1_tag tag);
Handle constructObject(Derived2_tag tag);
void deleteObject(Handle h);
void fun(Handle h, Derived1_tag tag);
void bar(Handle h, Derived2_tag tag);
Ось швидка реалізація
#include <map>
class Base
{
public:
virtual ~Base() {}
};
class Derived1 : public Base
{
};
class Derived2 : public Base
{
};
namespace Base_Impl
{
struct CompareHandle
{
bool operator()(Handle h1, Handle h2) const
{
return (h1.id < h2.id);
}
};
using ObjectMap = std::map<Handle, Base*, CompareHandle>;
ObjectMap& getObjectMap()
{
static ObjectMap theMap;
return theMap;
}
unsigned long getNextID()
{
static unsigned id = 0;
return ++id;
}
Handle getHandle(Base* obj)
{
auto id = getNextID();
Handle h{id};
getObjectMap()[h] = obj;
return h;
}
Base* getObject(Handle h)
{
return getObjectMap()[h];
}
template <typename Der>
Der* getObject(Handle h)
{
return dynamic_cast<Der*>(getObject(h));
}
};
using namespace Base_Impl;
Handle constructObject(Derived1_tag tag)
{
// Construct an object of type Derived1
Derived1* obj = new Derived1;
// Get a handle to the object and return it.
return getHandle(obj);
}
Handle constructObject(Derived2_tag tag)
{
// Construct an object of type Derived2
Derived2* obj = new Derived2;
// Get a handle to the object and return it.
return getHandle(obj);
}
void deleteObject(Handle h)
{
// Get a pointer to Base given the Handle.
//
Base* obj = getObject(h);
// Remove it from the map.
// Delete the object.
if ( obj != nullptr )
{
getObjectMap().erase(h);
delete obj;
}
}
void fun(Handle h, Derived1_tag tag)
{
// Get a pointer to Derived1 given the Handle.
Derived1* obj = getObject<Derived1>(h);
if ( obj == nullptr )
{
// Problem.
// Decide how to deal with it.
return;
}
// Use obj
}
void bar(Handle h, Derived2_tag tag)
{
Derived2* obj = getObject<Derived2>(h);
if ( obj == nullptr )
{
// Problem.
// Decide how to deal with it.
return;
}
// Use obj
}
Плюси і мінуси
При першому підході ви можете сконструювати Derived
класи в стеку. З другим підходом це не є варіантом.
При першому підході ви берете на себе витрати на два динамічні розподіли та розподіли на побудову та знищення а Derived
в стеці. Якщо ви будуєте та знищуєте Derived
об'єкт з вашої кучі, затратайте на ще одне виділення та розміщення. При другому підході ви покриваєте лише витрати на один динамічний розподіл та одну угоду розташування для кожного об'єкта.
З першим підходом ви отримуєте можливість використовувати virtual
функцію члена Base
. З другим підходом це не є варіантом.
Моя пропозиція
Я б пішов із першим рішенням, щоб я міг використовувати ієрархію класів та virtual
функції членів, Base
навіть якщо це трохи дорожче.
Base
, нормального абстрактного базового класу ("інтерфейс") та конкретних реалізацій без pimpl може бути достатньо.