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

From: Asger Mangaard (tmb_at_[hidden])
Date: 2005-09-28 09:02:39

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_at_[hidden]>
>> From: Martin Bonner <martin.bonner_at_[hidden]>
> [don't snip attributions to text you quote]
>> > From: Asger Mangaard [mailto:tmb_at_[hidden]]
>> >
>> >> 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.