Re: [boost] Are there any interest in a pimpl library?

From: Asger Mangaard (tmb_at_[hidden])
Date: 2005-09-27 10:57:48

> ----Original Message----
> From: Asger Mangaard [mailto:tmb_at_[hidden]]
> Sent: 27 September 2005 16:13
> To: boost_at_[hidden]
> Subject: Re: [boost] Are there any interest in a pimpl library?
>
>>> Could you be more specific as to what functionality such a library
>>> would supply? If you already have an implementation then an example
>>> of it's use would be interesting.
>
> That was my immediate reaction too.
>
>>> It is my understanding that the pimpl idiom is fairly simple yet
>>> also class specific. I currently implement it like this:
> [snip classic pimpl idiom]
>
>> The only thing my library does is to initialize the forward declared
>> class, using heap or static memory through policies. Also, provides an
>> easy way of accessing the data.
>>
>> Eg.
>>
>> .hpp
>>
>> boost::pimpl<struct CMyData> m_MyData;
>>
>> .cpp
>>
>> struct CMyData
>> {
>>   CMyData()
>>   : m_Integer(0)
>>   {
>>   }
>>   int m_Integer;
>> };
>>
>> /// Data access
>> m_MyData->m_Integer = 2341;
>>
>> The CMyData will be initialized the first time its data members are
>> accessed.
>
> That means each use of m_MyData operator ->() has got to check whether the
> structure is initialized or not, and initialize it if so.  Isn't it much
> easier to initialize the pimpl struct in the constructor of the outer
> class?
>
> I also don't see how much easier it can get to access the data than to
> write:
>
>   pimpl->m_Integer

The 'already initialized' check is optimal through a policy. The main
advantages are:

* Correct copying of pimpl data members. Eg.

.hpp
struct STest
{
  STest& operator = (const STest& _copy);

  boost::pimpl<struct CMyData> m_MyData;
};

.cpp
STest& STest::operator = (const STest& _copy)
{
  m_MyData = _copy.m_MyData;
  return *this;
}

would work, where as the raw way would be something like:

.hpp
struct STest
{
  STest& operator = (const STest& _copy);

  struct CMyData* m_MyData;
};

.cpp
STest& STest::operator = (const STest& _copy)
{
  m_MyData = _copy.m_MyData;
  return *this;
}

and would cause the CMyData pointer to be copied around.

This is probably the reason to why pimpl idioms are mostly used by
singleton-like classes (managers, components, etc.) With this new library
one can easily apply the pimpl idiom to all kinds of classes (game
objects, etc.)

· The new/delete/static calls are handled automatically. Eg. actually no
need for a con/destructor.

I hope this answers your questions.

Regards,
Asger Mangaard