About modify class data members problem

[zs0723]

Hi

i have an issue about the following case:

class A
{
int a ;
};

class B
{
A a;
}

so when we compile class A into a library a.so , B load a ' s
implemention dynamic.

Now i need to change A like this:

class A
{
int a;
int b;
}

and compile A to a libray a.so ,put into test environment , the
problem is that

i didn't recompile class B , so what's problem ?

from <<inside c++ object>> book ,we should recompile B athough it is
not modifed.

can you tell me what's problem if i didn't recomiple B class ,if it's
dependent class have modify data members ?

thanks

 

[zs0723]

Hi

   i have an issue about the following case:

   class A
   {
      int a ;
   };

  class B
  {
     A a;
  }

so when we compile class A into a library a.so , B load a ' s
implemention dynamic.

Now i need to change A like this:

class A
{
   int a;
   int b;

}

and compile A to a libray a.so ,put into test environment , the
problem is that

i didn't recompile class B , so what's problem ?

from <<inside c++ object>> book ,we should recompile B athough it is
not modifed.

can you tell me what's problem if i didn't recomiple B class ,if it's
dependent class have modify data members ?

thanks

what about if use pointer as a member

class B
{
A * p;
}

do i need to recompile ?

thanks

 

[Rolf Magnus]

You didn't modify it explicitly, but it was modified. The class B contains
the member A, which now has a changed object layout. That means that also
class B's object layout has changed. Btw: This usually also happens if you
add, remove or reorder virtual member functions in the base class.

what about if use pointer as a member

class B
{
A * p;
}

do i need to recompile ?

That is one way to get around this. Here is a link that describes how to
stay binary compatible. It's written specifically for KDE applications, but
most of it applies to non-KDE programs written in C++, too.
http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++

 

[zs0723]

You didn't modify it explicitly, but it was modified. The class B contains
the member A, which now has a changed object layout. That means that also
class B's object layout has changed. Btw: This usually also happens if you
add, remove or reorder virtual member functions in the base class.

Thanks for your answer , i see.

That is one way to get around this. Here is a link that describes how to
stay binary compatible. It's written specifically for KDE applications, but
most of it applies to non-KDE programs written in C++, too.http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++- Hide quoted text -

- Show quoted text -

But i think we still have problem if we use pointer. In the
implementation of B , we need to create a A object before use
the pointer , and if Class B didn't recompile , it'll use old
constrcutor of A to create A object.I think this is problem.

If i am wrong ,please correct me .Thanks

 

[Rolf Magnus]

Thanks for your answer , i see.


But i think we still have problem if we use pointer. In the
implementation of B , we need to create a A object before use
the pointer , and if Class B didn't recompile , it'll use old
constrcutor of A to create A object.I think this is problem.

If i am wrong ,please correct me .Thanks

It might be, yes, or at least operator new might, because it gets the wrong
size of its memory allocation. That's where the pimpl idiom comes in handy.
It's explained in the page that Il inked to above under "Using a d-Pointer".
Basically, instead of making B contain a pointer to A, you make A contain a
pointer to its internal data and allocate that dynamically. Then, for your
class B, A will always only contain one single pointer, and you're free to
change the members of the daa it points to. That's one more example of where
one more level of indirection solves the problem.

 

[Erik Wikström]

But i think we still have problem if we use pointer. In the
implementation of B , we need to create a A object before use
the pointer , and if Class B didn't recompile , it'll use old
constrcutor of A to create A object.I think this is problem.

An alternative would be to pass an A pointer to B's constructor, and
construct the A instance outside of B:

struct B
{
A* a;
B(A* a_) : a(a_) {}
};

Of course this only means that you no longer have to recompile B, but
you still need to recompile the part that that uses B.