C++ pimpl
so
so at so.so
Sun Jan 22 15:39:23 PST 2012
I have been asking that for some time now, i am afraid you won't get much
of an audience.
You can get rid of both additional allocation and indirection but it is
not pretty. We could definitely use some help/sugar on this.
http://www.artima.com/cppsource/backyard3.html
On Thu, 19 Jan 2012 22:48:39 +0200, Roberto Caravani <JFanatiker at gmx.at>
wrote:
> Qt for example uses the pimpl idiom for achieving ABI compatibility
> between releases. The problem is additional heap allocations, additional
> indirection and you pay for it, whether needed or not. (For example even
> derived classes in the same library pay for it.)
> I wondered whether this would still be necessary in D and I think not.
> In D, as interface files are automatically generated, it could be
> possible to have ones created with let's say a special "@private_impl"
> property or something. For these classes the object size would have to
> be stored as hidden static member in the library. The new operator could
> then simply read the size and allocate the needed space. Derived class
> methods can also use the size to calculate the offset of the derived
> class data members.
>
> So you would lose some optimizations, e.g. initializing of base members
> can't be inlined and stuff. But this is not possible with pimpl either
> and you gain the following:
> - You only pay for it if you want it. You can also use the standard .di
> file and lose the ABI compatiblity between versions if you so want and
> derived classes in the same library do not need to pay any additional
> overhead either.
> - It is completely transparent: If you later on decide you need ABI
> compatibility between releases, it's just a matter of a compiler switch
> and differend .di files.
> - I think it will also be more efficient than pimpl in all regards.
>
> I think this would be a real neat and very important feature, when it
> comes to shared libraries. Is there any plan to implement something like
> that in the future? Do I miss something?
>
> Best regards,
>
> Robert
More information about the Digitalmars-d
mailing list