[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: KFileDialog patch - request for comments
From:       Kuba Ober <kuba () mareimbrium ! org>
Date:       2002-07-15 13:18:42
[Download RAW message or body]

On czwartek 27 czerwiec 2002 10:30 pm, Trevor Harmon wrote:
> On Friday 28 June 2002 4:28 am, Waldo Bastian wrote:
> > > Something else I just thought of...I had to add a new data member to a
> > > dynamically allocated struct (KFileDialogPrivate) in order to save a
> > > copy of the QWidget pointer. But according to the following, adding
> > > data members to non-static structs breaks binary compatibility:
> >
> > Yes, but since these private structs are not part of the API it is not a
> > problem since they are not used outside the kfiledialo implementation
> > itself.
> >
> > In fact, that's the reason why we use FooBarPrivate *d; all over the
> > place.
>
> Hmm...so that document is wrong or, at best, misleading, since it says "You
> cannot add new data members to a class except static ones." It does not
> explicitly mention structs, but because internally structs are almost
> identical to classes, I figured it held for structs as well. Does the
> document need to be changed?
>
> http://developer.kde.org/documentation/library/kdeqt/kde3arch/devel-binaryc
>ompatibility.html

It should probably be changed to say "all of this applies to *public* 
interfaces only". Nobody's going to get hurt if you change members of a 
private struct used only by the implementation. Alas, private 
pointer-to-struct members are there so that the struct can be changed, and 
both the sizeof(class) and its layout stay as they were, so that BC is 
preserved.

Another story is when you have this:

class Foo {
  public:
  ...
  private:
    int bar1;
};

If you then add another private member bar2, you're in trouble since *both* 
sizeof(Foo) and its layout (i.e. members and their placement) changes, and 
that definitely breaks BC (notably because old code will allocate too little 
space for the new Foo, so by accessing bar2 you're likely to overwrite heap 
of whatever object is next to the Foo's instance).

Cheers, Kuba Ober
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]