Aside from access specifiers (private, public, protected), what differentiates structures and unions from classes in C++? I have been told that in C++, classes and their associated components are instantiated in memory in pretty much random order, but structs and unions are instantiated in a fixed order? Is this true? Where can I find this information?

Recommended Answers

All 11 Replies

There is no difference between structures and c++ classes other than default access. Unions are the same as they are in C -- all members of a union occupy the same memory location.

>>classes and their associated components are instantiated in memory in pretty much random order, but structs and unions are instantiated in a fixed order? Is this true?
I don't know -- never heard of that. Both structure and class objects should be allocated in the order in which they are declared. If allocated dynamically then the memory will be in some memory that is unknown to the program (the memory allocation functions will of course know).

Both structure and class objects should be allocated in the order in which they are declared. If allocated dynamically then the memory will be in some memory that is unknown to the program (the memory allocation functions will of course know).

I agree with Dragon, even if a random memory is acquired when malloc is used, the pointers in the class should occupy memory in the order they are declared. This is a code wich proves this point

#include<iostream>
#include<stdlib.h>
using namespace std ;

class c
{
public:
	char *a ;
	c ( ){
		a = (char *)malloc ( 50 ) ;
		b = (int *)malloc ( 50 ) ;
		cout << (unsigned)&(this->a) <<endl ;
		cout << (unsigned)&(this->b) ;
	}
	int *b ;
} ;

int main()
{
	c cobj1, cobj2 ;
}

>>This is a code wich proves this point
Your code proves nothing.

>>the pointers in the class should occupy memory in the order they are declared
Don't count on it. 1) never use malloc in c++. 2) whether malloc or new is used there is no guarentee how the memory will be allocated. Might be consecutive, and might not. Lets say you have three pointers, a, b and c delete a and reallocate it with a larger amount of memory. Will it use the old memory location (no because its not big enough). Will it follow the memory allocated for c ? Probably not especially if some other pointer d was previouslly allocated and then deleted.

When I said it would be allocated consecutively I meant this:

class MyClass
{
   // blabla
};

int main()
{
    MyClass a;
    MyClass b;
}

In the above the memory for MyClass b will probably immediately follow MyClass a. But again you can't count on it because it will be implementation dependent (the compiler is free to allocate memory any way it wishes.)

Another argument against it is what happens when you have two processes that allocate memory. Process A aloocates a pointer, then process B allocates a pointer, then process A allocates another pointer. The memory locations allocated by process A may or may not be consecutive because process B allocated memory between the two pointers in process A.

Well, I have to agree with what you said, and at the same time what I really wanted to say was the memory allocated may be dynamic but the memory allocated to reference this dynamic memory during compile time will be in order. That is the pointers a & b will be consecutive. Of course the memory referenced by them may not be, for all the reasons you mentioned.

EDIT:
Using new is better, I do know of it yet lets say I still stick to C, I'll change myself though, thank you

Ok. Is it possible that a structure in C is allocated in memory consecutively due to using malloc, but in C++, the new operator is forced to allocate memory for a structure consecutively to stay consistent with C? How does the default new operator handle classes vs. structures?

This is very puzzling to me...

I still don't know exactly what you mean. Are you talking about the order in which a program executes the lines, for instance

char* a = new char[25];
// something here
char* b = new char[25];
// more stuff here

Or are you asking if the memory allocated to b above is adjacent to the memory allocated to a. Don't get bogged down in all the nitty-gritty details because that will be compiler and operating system dependent. There are lots of different kinds of memory allocation schemes, even within the same operating system. MS-Windows has a least seven different schemes. I don't know how many schemes *nix has.

>>How does the default new operator handle classes vs. structures?
They are handled the same. In c++ the ONLY difference between a class and a structure is the default access type. structures default access is public while classes is private. Otherewise they are exactly the same.

> but structs and unions are instantiated in a fixed order? Is this true? Where can I find this information?
Yes (for C anyway), members of a struct are arranged through memory in the order in which you declare them. What you have little control over however is what the padding and alignment between members of the struct is like. Further, &whole_struct and &whole_struct.first_member are guaranteed to evaluate to the same address (though not the same type).

AFAIK, the same is true for C++, but there is more excess baggage of class information intermixed with the members, and I'm not sure about whether the first data member at the start rule applies.

For C, read the pointer comparison semantics in the standard
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n869/

The C++ standard does not specify layout, so the internal layout of a class or structure will vary by compiler. (Though, for most compilers the first thing is a pointer to the v-table, then the fields, so old C code that relies on struct and struct.first_member will probably compile just fine.)

As Salem indicated, it is always dangerous to assume anything about actual memory storage.

this is what the C++ standard specifies about the layout (note that there are no separate specifications for struct and class)

Nonstatic data members of a (non-union) class declared without an intervening access-specifier are allocated so that later members have higher addresses within a class object. The order of allocation of nonstatic data members separated by an access-specifier is unspecified. Implementation alignment requirements might cause two adjacent members not to be allocated immediately after each other; so might requirements for space for managing virtual functions and virtual base classes.

and, earlier:

A structure is a class defined with the class-key struct; its members and base classes are public by default.

a class with just a single access specifier at the beginning and no virtual functions or base classes will be laid out as a struct is laid out in C.

> Where can I find this information?
a good (but dated) reference for object layout in C++: Inside the C++ Object Model by Stan Lippman http://www.informit.com/store/product.aspx?isbn=0201834545

The C++ standard does not specify layout, so the internal layout of a class or structure will vary by compiler. (Though, for most compilers the first thing is a pointer to the v-table, then the fields, so old C code that relies on struct and struct.first_member will probably compile just fine.)

As Salem indicated, it is always dangerous to assume anything about actual memory storage.

Great. I got this question at a job interview. This question, among others, were posed by engineers to me. Of course I only gave the difference as the access specifiers being public by default...so when he told me about the memory layout being different, it went against me because I didn't know it.

There were a few others that they gave me that I know were wrong. How does one go about handling a situation like this, when the interviewer is clearly wrong?

Oh well...nevermind. Thanks everyone for your input...

Don't worry about it. You don't want to work with a bunch of Real Programmers. Anyone dinking around with the bits of class layout in memory, or caring how it actually is layed out, is either writing a compiler or is doing a disservice to their employer.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.