Is this bad C++?

Started by
13 comments, last by Polymorphic OOP 19 years, 6 months ago
I'm wondering about how C++ classes are stored on the heap and whether it can differ among compilers and platforms. Let's say I have this simple class: class A { public: int iar[3]; A() {} }; A *pA = new A[2]; Now, is it safe to assume that ((int*)pA)[3] actually points to pA[1].ia[0]? And if so, is it an accepted scheme to use? Next example: class A { public: int x; int y; A() {} }; A *pA = new A[2]; Same question; can you assume ((int*)pA)[2] points to pA[1].x?
Advertisement
That's compiler and architecture specific, because of padding and alignment.
But why would you want to do something like that?

[Edited by - noVum on September 27, 2004 7:16:20 PM]
I'm pretty sure that it's not safe to assume any of these.

What use would that have?
Both your assumptions are correct. As to whether it being an acceptable scheme or not is a matter of taste i think. It's pretty safe to assume. But the c++ standard does not guarantee that soprt of behaviour, and those assumptions wont hold when you have derived classes.

Im sure Fruny has the c++ standanrd official technical lowdown on this though.

[edit]
also what noVum said...
[/edit]
[size=2]aliak.net
Quote:Original post by androw
Now, is it safe to assume that ((int*)pA)[3] actually points to pA[1].ia[0]? And if so, is it an accepted scheme to use?


You can write &(pA[num / 3].iar[num % 3]) to get the address of the desired element.

BTW if you have a class without virtual functions and just public members, it behaves like a usual old struct. In this case your addressing scheme should work.

Making some mebers private should work either, but do not use virtual functions. Also pay attention to padding.
I use these a lot in Vertex Arrays and VBOs:

class Vertex{
public:
float x,y,z;
};

Vertex *mesh=Vertex[triangle_count*3];

glVertexPointerf(*,*,*,mesh);

Is completely correct with many compilers but i can see memory fragmentation cause problems with implementations where blocks can be allocated fragmentated (i have have never seen one, i don't even think there are any).

So i think (i don't know it completely sure) you can assume that, yes.

Btw, if not that would mean that this could get compiled wrong:

char txt[]="Blabla";
txt[1]='i'; // compiled as *(txt+(sizeof(char)*1))='i';

With memory fragmentation, txt[1] might not be the base address + the memory needed to store one char type value so it would probably crash.
Well, my intention with the desribed scheme are as follows:

I have a class called Vertex who's sole data member is an array of three floats describing the x, y and z components of a point in R3. Vertex also has some utility member functions for manipulating these components.

Now, in my program I need to be able to access an array of vertexes as an continuos array of floats i.e. {x1, y1, z1, x2, y2...}.

I've been thinking of several ways to accomplish this. But thought the described scheme was simple yet ugly. Does anyone know a preferred way of handling this?
Ok, what Tree Penguin is doing is exactly what I'm working on :)
The cleanest way would be copying the vertex data into a seperate buffer and passing that to he API, I suppose.
[edit]
You can also change you vector class to a struct. If you have no virtual methods and allocate the vectors as a block, your assumptions will hold true.
[/edit]
A struct is the same as a class, but with public access by default whereas a class has private access by default.

This topic is closed to new replies.

Advertisement