Jump to content
  • Advertisement
Sign in to follow this  
androw

Is this bad C++?

This topic is 5410 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
A struct is the same as a class, but with public access by default whereas a class has private access by default.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!