Programming Forums > Application Development > C++

coder0xff · Jun 2nd, 2006, 12:12 PM

I have a class Vector. The first members I have typed into the class:

Scalar x;
Scalar y;
Scalar z;

Scalar is a typedef for double. There are several other members (data and code) I examined this class at runtime and discovered that the doubles are not packed tightly in memory, ie: &x+sizeof(Scalar) != &y. This expression evaluates to true. Is there a way I can ensure they are adjacent in memory? I want to be able to use the data in calls to OpenGL array routines, but would rather avoid converting each Vector to a struct PackedVert3{Scalar x,y,x;}

nnxion · Jun 2nd, 2006, 12:36 PM

I'm confused, you want x, y, and z which are just plain doubles to be adjacent, but are not using arrays to store them?

DaWei · Jun 2nd, 2006, 12:53 PM

The compiler packs the members as it deems best. One can force the issue at the risk of blowing portability.

Animatronic · Jun 2nd, 2006, 12:56 PM

If you have other data members after the XYZ you wont be able to pass them as an array anyway, unless it takes in a stride value in which case the fact that the doubles arent closely packed shouldnt matter.

EDIT: scrub that of course it would still matter, try putting your XYZ at the start of the structure ten they shouldnt need any packing.

volatile · Jun 2nd, 2006, 2:24 PM

I see I'm not the only one confused. Why do you want them to be adjacent, why do you care. Thing is, they most likely are adjacent, you just have'nt realised it.

As DaWei said, the compiler will pack your data as it see fit. Lets look at an example ( I compiled this with Dev-C++):

(Toggle Plain Text)

#include <iostream>

using namespace std;

typedef double Scalar;
int main()
{
	Scalar x;
	Scalar y;
	Scalar z;
	
	cout << &x << endl;
	cout << &y << endl;
	cout << &z << endl;
}

output:

(Toggle Plain Text)

0x22ff70
0x22ff68
0x22ff60

Even though x came first in the source code, it is stored last in memory. They are however packed titely. Considering the fact that a double is eight byte, this came to no surprise.

You cant assume that data you define in your source is sequential.

Also your code is wrong to begin with.

(Toggle Plain Text)

&x+sizeof(Scalar) != &y

WRONG!!!!!

You have to be carefull when doing arithmetic with pointers or references. Lets look at an example:

(Toggle Plain Text)

int *ptr = 0;
cout << ptr << endl;
ptr++
cout << ptr <<endl;

output:

(Toggle Plain Text)

0
0x4

You'd might think p was 1 after increment, but its 4.

Similarly *(p+2) is element at address 8, the same as p[2]. Its the same with references. This is how your code should be:

(Toggle Plain Text)

&x+1 != &y

Since sizeof(Scalar) is 8, &x + 8 is the eight element of type Scalar after &x. The same as saying address of x pluss 8*8 wich is pluss 40.

Animatronic · Jun 2nd, 2006, 2:40 PM

Quote:

Even though x came first in the source code, it is stored last in memory. They are however packed titely.

This is because you are putting x,y,z on the stack, so you are just showing how the stack is being implemented on your compiler, nothing to do with how data members in structs are laid out.

The test:

(Toggle Plain Text)

#include <stdio.h>

struct foo
{
	double x,y,z;
};

int main(void)
{
	struct foo f;
	printf("%p,%p,%p\n",&f.x,&f.y,&f.z);

	return 0;
}

shows different.

Good catch on the &x+sizeof(Scalar) != &y thing though.

Quote:

You cant assume that data you define in your source is sequential.

But I think data members have to be sequential in a struct/class to how they're defined.

coder0xff · Jun 2nd, 2006, 2:42 PM

I'm a retard!

I just realised that before seeing your post, about the whole only adding one thing. I was about to make a post saying that. :-)

Anway, the were packed in the first place :-).

void glVertexPointer(GLint size, GLenum type, GLsizei stride, const GLvoid *pointer);

Does take a stride size between triplets, but still needs each triplet packed.

Thanks everybody! - I refer you to my signatures quote.

volatile · Jun 2nd, 2006, 3:21 PM

You were right about the stack thing Animatronic.

Crap. I though the compiler would arrange data as It saw fit..I mean, lets say you interweave global chars and ints. This would make many ints not on a four byte boundary. I tried an example. The compiler would only padd the data, no rearranging. Not exactly space efficient.

lectricpharaoh · Jun 2nd, 2006, 6:15 PM

Okay, I wrote this reply before seeing you'd solved the problem, but I'll post it anyways in case you or someone else hits a similar issue in the future.

Quote:

Originally Posted by coder0xff

Scalar is a typedef for double. There are several other members (data and code) I examined this class at runtime and discovered that the doubles are not packed tightly in memory, ie: &x+sizeof(Scalar) != &y. This expression evaluates to true. Is there a way I can ensure they are adjacent in memory? I want to be able to use the data in calls to OpenGL array routines, but would rather avoid converting each Vector to a struct PackedVert3{Scalar x,y,x;}

Structure/class packing is generally done to provide for the fastest memory access of the members. If you will be using your own methods most of the time, and only calling OpenGL functions at the end of a cycle, then a possible approach would be to leave the packing as is, but construct a pack() method to return an instance (or reference to) such a packed structure. To me, this seems a reasonable compromise, but given that I've never worked with OpenGL, it might not be an appropriate solution.

Jun 2nd, 2006, 12:12 PM	#1
coder0xff Unverified User Join Date: Mar 2006 Posts: 18 Rep Power: 0	Adjacent data members I have a class Vector. The first members I have typed into the class: Scalar x; Scalar y; Scalar z; Scalar is a typedef for double. There are several other members (data and code) I examined this class at runtime and discovered that the doubles are not packed tightly in memory, ie: &x+sizeof(Scalar) != &y. This expression evaluates to true. Is there a way I can ensure they are adjacent in memory? I want to be able to use the data in calls to OpenGL array routines, but would rather avoid converting each Vector to a struct PackedVert3{Scalar x,y,x;} __________________ Brent Two things are infinite: the universe and human stupidity; and Im not sure about the universe. -- Albert Einstein Last edited by coder0xff; Jun 2nd, 2006 at 12:22 PM.

Jun 2nd, 2006, 12:36 PM	#2
nnxion Programming Guru Join Date: Jun 2005 Location: elemental plane Posts: 1,429 Rep Power: 5	I'm confused, you want x, y, and z which are just plain doubles to be adjacent, but are not using arrays to store them? __________________ "Employ your time in improving yourself by other men's writings, so that you shall gain easily what others have labored hard for." -- Socrates

Jun 2nd, 2006, 12:53 PM	#3
DaWei Resident Grouch Join Date: Jun 2005 Posts: 6,453 Rep Power: 10	The compiler packs the members as it deems best. One can force the issue at the risk of blowing portability. __________________ Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code. Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

Jun 2nd, 2006, 2:24 PM	#5
volatile Newbie Join Date: Nov 2005 Posts: 18 Rep Power: 0	I see I'm not the only one confused. Why do you want them to be adjacent, why do you care. Thing is, they most likely are adjacent, you just have'nt realised it. As DaWei said, the compiler will pack your data as it see fit. Lets look at an example ( I compiled this with Dev-C++): (Toggle Plain Text) #include <iostream> using namespace std; typedef double Scalar; int main() { Scalar x; Scalar y; Scalar z; cout << &x << endl; cout << &y << endl; cout << &z << endl; } #include <iostream> using namespace std; typedef double Scalar; int main() { Scalar x; Scalar y; Scalar z; cout << &x << endl; cout << &y << endl; cout << &z << endl; } output: (Toggle Plain Text) 0x22ff70 0x22ff68 0x22ff60 0x22ff70 0x22ff68 0x22ff60 Even though x came first in the source code, it is stored last in memory. They are however packed titely. Considering the fact that a double is eight byte, this came to no surprise. You cant assume that data you define in your source is sequential. Also your code is wrong to begin with. (Toggle Plain Text) &x+sizeof(Scalar) != &y &x+sizeof(Scalar) != &y WRONG!!!!! You have to be carefull when doing arithmetic with pointers or references. Lets look at an example: (Toggle Plain Text) int ptr = 0; cout << ptr << endl; ptr++ cout << ptr <<endl; int ptr = 0; cout << ptr << endl; ptr++ cout << ptr <<endl; output: (Toggle Plain Text) 0 0x4 0 0x4 You'd might think p was 1 after increment, but its 4. Similarly (p+2) is element at address 8, the same as p[2]. Its the same with references. This is how your code should be: (Toggle Plain Text) &x+1 != &y &x+1 != &y Since sizeof(Scalar) is 8, &x + 8 is the eight element of type Scalar after &x. The same as saying address of x pluss 88 wich is pluss 40.

Jun 2nd, 2006, 2:42 PM	#7
coder0xff Unverified User Join Date: Mar 2006 Posts: 18 Rep Power: 0	I'm a retard! I just realised that before seeing your post, about the whole only adding one thing. I was about to make a post saying that. :-) Anway, the were packed in the first place :-). void glVertexPointer(GLint size, GLenum type, GLsizei stride, const GLvoid pointer); Does take a stride size between triplets, but still needs each triplet packed. Thanks everybody! - I refer you to my signatures quote. __________________ Brent Two things are infinite: the universe and human stupidity; and Im not sure about the universe.* -- Albert Einstein

Jun 2nd, 2006, 12:56 PM	#4
Animatronic Programmer Join Date: Jun 2005 Posts: 99 Rep Power: 4	If you have other data members after the XYZ you wont be able to pass them as an array anyway, unless it takes in a stride value in which case the fact that the doubles arent closely packed shouldnt matter. EDIT: scrub that of course it would still matter, try putting your XYZ at the start of the structure ten they shouldnt need any packing.

Jun 2nd, 2006, 3:21 PM	#8
volatile Newbie Join Date: Nov 2005 Posts: 18 Rep Power: 0	You were right about the stack thing Animatronic. Crap. I though the compiler would arrange data as It saw fit..I mean, lets say you interweave global chars and ints. This would make many ints not on a four byte boundary. I tried an example. The compiler would only padd the data, no rearranging. Not exactly space efficient.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Programming Forums > Application Development > C++

Adjacent data members