Hi,
What is the memory layout of an object, and the derived object.
For example :

class A
{
private:
int prv_data;
protected:
int pro_data;
public:
int pub_data;
A(){prv_data = 10;}
void Aprint();
};

class B : public A
{
int pro_data;
public:
void Bmember1();
void Bprint();
};

Does it depend on the compiler ?

int main()
{
B b;
int *ptr;

ptr = (int *)&b;
*ptr = 1000;
ptr++;
*ptr = 2000;
ptr++;
*ptr = 3000;
ptr++;
*ptr = 4000;

return 0;
}

is setting only the private element of class A to 1000, rest are not
being set.

On Jun 29, 10:52am, Peskov Dmitry <vamsi.kom...@gmail.com> wrote:
> Hi,
> What is the memory layout of an object, and the derived object.
> For example :
>
> class A
> {
> private:
> int prv_data;
> protected:
> int pro_data;
> public:
> int pub_data;
> A(){prv_data = 10;}
> void Aprint();
>
> };
>
> class B : public A
> {
> int pro_data;
> public:
> void Bmember1();
> void Bprint();
>
> };
>
> Does it depend on the compiler ?
>
> int main()
> {
> B b;
> int *ptr;
>
> ptr = (int *)&b;
> *ptr = 1000;
> ptr++;
> *ptr = 2000;
> ptr++;
> *ptr = 3000;
> ptr++;
> *ptr = 4000;
>
> return 0;
>
> }
>
> is setting only the private element of class A to 1000, rest are not
> being set.

You can inspect the memory layout of a class by breaking in the
debugger, then taking the address of the object (b in your case) and
reading the contents of the memory from that location onwards.
I ran your above code in Visual Studio 2008 (except assigning ptr to
&b and incrementing the pointer etc). I assigned 10, 20 and 30 to
pri_data, pro_data, and pub_data respectively so that I can easily
identify them when I read the memory.

Here's what I found:
1. The memory contained pri_data first, pro_data second and the third
was pub_data. This is because you declare them in that order. Reverse
the order and you will find the memory is laid out as pub_data,
pro_data and pri_data.

Don't know if this is required by C++ std. or the compiler does it
this way. Also it is a good practice to initialize member variables in
the constructor in the order in which they are declared in the class
declaration. (from Scott Meyers book Effective C++: 50 specific ways
to improve your program and design, 2nd. edition).

2. Contents of the inherited class B come after A.

Hope that s.

Peskov Dmitry wrote:
> Hi,
> What is the memory layout of an object, and the derived object.
> For example :
>
> class A
> {
> private:
> int prv_data;
> protected:
> int pro_data;
> public:
> int pub_data;
> A(){prv_data = 10;}
> void Aprint();
> };
>
> class B : public A
> {
> int pro_data;
> public:
> void Bmember1();
> void Bprint();
> };
>
> Does it depend on the compiler ?
>
> int main()
> {
> B b;
> int *ptr;
>
> ptr = (int *)&b;
> *ptr = 1000;
> ptr++;
> *ptr = 2000;
> ptr++;
> *ptr = 3000;
> ptr++;
> *ptr = 4000;
>
> return 0;
> }
>
> is setting only the private element of class A to 1000, rest are not
> being set.

See
http://www.research.att.com/~bs/bs_faq2.html#layout-obj

Heskov Dmitry schrieb:
> Hi,
> What is the memory layout of an object, and the derived object.
[...]
> Does it depend on the compiler ?

In general yes.
The standard only makes few restrictions to the memory layout. E.g.
members of one class that are not intercepted by private: or so have to
be in the order that they are defined.
But there are no restrictions about base classes. They need not to have
a hard relation to the derived class at all. In case of virtual base
classes (e.g. interfaces) this ist obviously the case.

> int main()
> {
> B b;
> int *ptr;
>
> ptr = (int *)&b;

From here it is definitely undefined behaviour. B is no POD.
B need not to start with A and furthermore the first storage ob B might
not be any member at all.

> *ptr = 1000;
> ptr++;
> *ptr = 2000;
> ptr++;
> *ptr = 3000;
> ptr++;
> *ptr = 4000;
>
> return 0;
> }
>
> is setting only the private element of class A to 1000, rest are not
> being set.

Undefined behaviour, as I said.

However, many compilers start with the members in the order as they are
declared and place bas classes before their derived class. Furthermore
everything is usually preceeded with a virtual table pointer if the
class is polymorphic. Each polymorphic base class has it's own virtual
table pointer, except for the first base class. In this case the virtual
table of the base is a slice of the virtual table of the derived
class(es), therefore their two vtbl pointers are collapsed.
This is as many compilers behave. But not one of this words is reliable.
It may even change with the compiler version. E.g. the compiler may sort
members by size and/or alignment to save padding space. Debug memory
management may place additional guard areas at certain locations in the
memory layout.

So the answer is quite simple. You must not ask this question, since the
answer will not be reliable. Do not rely on the memory layout of the
class tree. Only PODs have a more or less defined memory layout.


Marcel

On Jun 29, 1:52pm, Peskov Dmitry <vamsi.kom...@gmail.com> wrote:
> Hi,
> What is the memory layout of an object, and the derived object.
> For example :
>
> class A
> {
> private:
> int prv_data;
> protected:
> int pro_data;
> public:
> int pub_data;
> A(){prv_data = 10;}
> void Aprint();
>
> };
>
> class B : public A
> {
> int pro_data;
> public:
> void Bmember1();
> void Bprint();
>
> };
>
> Does it depend on the compiler ?
>
> int main()
> {
> B b;
> int *ptr;
>
> ptr = (int *)&b;
> *ptr = 1000;
> ptr++;
> *ptr = 2000;
> ptr++;
> *ptr = 3000;
> ptr++;
> *ptr = 4000;
>
> return 0;
>
> }
>
> is setting only the private element of class A to 1000, rest are not
> being set.

The memory layout of a class is compiler dependent. The following
article should :

http://www.eventhelix.com/realtimema...erformance.htm

Memory layout for inherited classes is explained in:

http://www.eventhelix.com/realtimema...formance2..htm

--
http://www.EventHelix.com/EventStudio
Sequence diagram based systems engineering tool

In article <2f35231f-96fc-406a-a078-d77fbb1799d6
@i18g2000prn.googlegroups.com>, vamsi.komati@gmail.com says...
> Hi,
> What is the memory layout of an object, and the derived object.

[ ... ]

> Does it depend on the compiler ?

Partly. If there's no private/public/protected label between them, items
in an object are required to be placed at increasing addresses. When
there is an intervening private/protected/public label, there is no
guarantee about relative ordering from the standard.

As far as base classes go, IF you're dealing with single inheritance
quite a few compilers put the base class at the beginning of the derived
class. This makes it trivial to convert an object to its base class
object (i.e. the same address, treated as a pointer to the base class,
works). Obviously when you have multiple inheritance, the compiler can
only place one base class at the beginning of the derived class objects.

--
Later,
Jerry.

The universe is a figment of its own imagination.