From: "Asger Mangaard" <tmb@tmbproductions.com>
I'm sorry, but I'm really having a hard time figuring out if you're strickly ironic in your answer or not?
The only thing remotely ironic in what I wrote was WRT the one-versus-two-line declaration. That is, your scheme avoids a separate line for the declaration of the impl type, and I was noting that it was only marginally better.
Do you like the idea or not?
It seems as if it could be quite useful.
From: "Asger Mangaard" <tmb@tmbproductions.com>
From: Martin Bonner <martin.bonner@pitechnology.com> [don't snip attributions to text you quote]
This wasn't irony. I was being prescriptive.
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.
I'd still like to hear what you have in mind here.
easy way of accessing the data.
.hpp
boost::pimpl<struct CMyData> m_MyData;
No forward declaration on a separate line is helpful, I suppose.
Here's where I was acknowledging a marginal benefit.
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."
What do you think of this?
advantages are:
* Correct copying of pimpl data members. Eg.
That's helpful.
That's not irony. I was noting that your approach was helpful on this point.
.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.
Clearly, there's no irony here. There was a tiny bit of sarcasm in that few would copy the pointer as shown.
I hope this answers your questions.
It would have been helpful to have listed these things in your original post.
Here I was pointing out that your initial points omitted a great many details that were necessary for us to understand your proposal and took many replies to extract. This, too, was prescriptive so that your future messages will be more helpful up front. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;