Hi, I'm sorry, but I'm really having a hard time figuring out if you're strickly ironic in your answer or not? Do you like the idea or not? Regards, Asger Mangaard
--===============1344030888==
From: "Asger Mangaard" <tmb@tmbproductions.com>
From: Martin Bonner <martin.bonner@pitechnology.com> [don't snip attributions to text you quote]
From: Asger Mangaard [mailto:tmb@tmbproductions.com]
The only thing my library does is to initialize the forward declared class, using heap or static memory through policies. Also, provides an
What about pimpl types with non-default constructors? I can see an assignment operator taking an impl *, making your proposed class like a reseatable smart pointer. That would permit the client to construct the impl any way necessary and then just hand it off to your class.
easy way of accessing the data.
.hpp
boost::pimpl<struct CMyData> m_MyData;
No forward declaration on a separate line is helpful, I suppose.
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?
The 'already initialized' check is optimal through a policy. The main
I take it you mean that your policy can construct the impl instance when the pimpl is instantiated and then opt to not check in the member selection operator? If so, that should probably be the default mechanism. The policy you describe should be called something like, "lazy_creation."
advantages are:
* Correct copying of pimpl data members. Eg.
That's helpful.
.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; }
Actually, you'd just let the compiler generate the copy assignment operator in this case, which is quite useful.
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.
...so of course you'd manage the memory yourself. This *is* an advantage to your proposal.
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.)
I don't limit my use to such types.
ยท The new/delete/static calls are handled automatically. Eg. actually no need for a con/destructor.
...unless needed by the impl type.
I hope this answers your questions.
It would have been helpful to have listed these things in your original post.