Unused PIMPL pointer in TagLib::Tag

[Stephen Hewitt]

Yeah, I've seem the pattern before (although I've never heard it called
"d-pointer", but rather other names including "The PIMPL Idiom"). Still, as
applied to the TabLib::Tag class its usage seems a little strange since it's
abstract and not a single methods uses the indirection that makes the idiom
work (in this case indirection through TagLib::Tag::d). I can see that if
maintaining binary compatibility while exposing raw C++ classes is important
the change I originally suggested wont work because it will change the sizes
of all the classes which derive from TagLib::Tag.

Steve

On Tue, Dec 15, 2009 at 11:44 PM, Scott Wheeler <wheeler at kde.org> wrote:

>
> On Dec 15, 2009, at 9:20 AM, Stephen Hewitt wrote:
>
> > Can you elaborate on these ABI reasons or point me somewhere that
> > does? I didn't notice any assumptions about the layout/size of
> > TagLib::Tag made in the code other that via the header in question?
> > If there is a valid reason I'd suggest a comment was in order.
>
>
> The problem is the size of the object in the shared library -- that
> can't change between releases or else it will break applications that
> use that interface when upgrading TagLib.  If you need to add an
> attribute in a future release, you need to reserve a pointer to a
> private object for future use.  Creating a "d-pointer" like that is
> standard practice in C++ libraries that attempt to maintain binary
> compatibility across releases:
>
>
> http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B#Using_a_d-Pointer
>
> -Scott
> _______________________________________________
> taglib-devel mailing list
> taglib-devel at kde.org
> https://mail.kde.org/mailman/listinfo/taglib-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/taglib-devel/attachments/20091216/a3cbe8b1/attachment.htm