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

27 Sep 2005

      ...
----Original Message----
From: Asger Mangaard [mailto:tmb@tmbproductions.com]
Sent: 27 September 2005 16:13
To: boost@lists.boost.org
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