To use a pointer or not.

[a02hansj]

I've created a simple three-dimensional vector class for a small vector
math library. The class members are three doubles 'x', 'y' and 'z'.
The idea is to represent polygon vertices as an array of pointers to 3d
vectors. My question is, should I make the x, y and z members of the
vecctor pointers? What are the general guidelines of when to use
pointers or just plain variables?

--
Hans

[ben]

My question is, should I make the x, y and z members of the
vecctor pointers?

What do you mean "members of the vector pointers"? Does a pointer have a
member??

ben

[ben]

Oops, sorry! I must be sleeping.

Keep x, y and z private members and wrap them up with proper member
functions. This way even if you later decide to change them to pointers, you
won't break user code (all encapsulation is about).

ben

What do you mean "members of the vector pointers"? Does a pointer have a
member??

ben

[Victor Bazarov]

a0******@NOstudent.SPAMhis.se wrote:

I've created a simple three-dimensional vector class for a small vector
math library. The class members are three doubles 'x', 'y' and 'z'.
The idea is to represent polygon vertices as an array of pointers to 3d
vectors. My question is, should I make the x, y and z members of the
vecctor pointers?
No.
What are the general guidelines of when to use
pointers or just plain variables?

Common sense. To keep three doubles directly in your vector you will
need 3*sizeof(double) bytes. To keep them as pointers in your vector
you will need at least 3*(sizeof(double) + sizeof(double*)) plus you will
have to perform indirection, you will have to make sure the pointers are
valid and so on. What do you gain by making them pointers? The size of
the vector object itself is less by (3*(sizeof(double)-sizeof(double*)).
Is that a smart move? I don't think so.

You could do a bit better: keep them as a single pointer to three doubles
(an array) and provide some kind of fast and lean allocation mechanism to
avoid going through the generic 'new[]' and 'delete[]' all the time.
That takes the size of your vector down by as much as
(3*sizeof(double) - sizeof(double*)), which can be viewed as significant.
You still need to perform indirection, and allocation, and deallocation,
and validation, and copying is not as trivial as with straight doubles,
and so on.

V

[a02hansj]

ben <be******@hotmail.com> wrote:

Oops, sorry! I must be sleeping.

Keep x, y and z private members and wrap them up with proper member
functions. This way even if you later decide to change them to pointers, you
won't break user code (all encapsulation is about).

ben

What do you mean "members of the vector pointers"? Does a pointer have a
member??

ben

Yeah I'm sorry. I meant "members of the vector _class_".
And the members are private and I have public getters and setters.

--
Hans

[a02hansj]

Victor Bazarov <v.********@comacast.net> wrote:

a0******@NOstudent.SPAMhis.se wrote:

I've created a simple three-dimensional vector class for a small vector
math library. The class members are three doubles 'x', 'y' and 'z'.
The idea is to represent polygon vertices as an array of pointers to 3d
vectors.

My question is, should I make the x, y and z members of the
vecctor pointers?

No.

What are the general guidelines of when to use
pointers or just plain variables?

Common sense. To keep three doubles directly in your vector you will
need 3*sizeof(double) bytes. To keep them as pointers in your vector
you will need at least 3*(sizeof(double) + sizeof(double*)) plus you will
have to perform indirection, you will have to make sure the pointers are
valid and so on. What do you gain by making them pointers? The size of
the vector object itself is less by (3*(sizeof(double)-sizeof(double*)).
Is that a smart move? I don't think so.

Well, what I was thinking might be in favor of making them pointers was
that they end up on the heap, rather than the stack. And if I have a
huge honking lot of these little things, I'd rather not fill up the
stack with that.
--
Hans

[Karl Heinz Buchegger]

a0******@NOstudent.SPAMhis.se wrote:

Common sense. To keep three doubles directly in your vector you will
need 3*sizeof(double) bytes. To keep them as pointers in your vector
you will need at least 3*(sizeof(double) + sizeof(double*)) plus you will
have to perform indirection, you will have to make sure the pointers are
valid and so on. What do you gain by making them pointers? The size of
the vector object itself is less by (3*(sizeof(double)-sizeof(double*)).
Is that a smart move? I don't think so.
Well, what I was thinking might be in favor of making them pointers was
that they end up on the heap, rather than the stack.

But the pointers will still be 'on the stack'.
And if I have a
huge honking lot of these little things, I'd rather not fill up the
stack with that.

Don't worry, You won't have much of them 'on the stack'.
You can always allocate the whole vector object dynamically.

In general - allocate dynamically if:
* you don't know in advance how many
(which is not the case in your case. You know that your vector
contains exactly 3 doubles)
* you need polymorphism and have a need to polymorphic objects
in a container
(which is not the case. The doubles in that class will stay doubles
for a long time)
* your class is extremely large.
(which is not the case. 3 doubles is *not* large. 300000 would be, but
3 is definitly not)

Otherwise prefer the cleanest and simplest design. And that is: If you want
3 doubles, then make them 3 doubles.

--
Karl Heinz Buchegger
kb******@gascad.at

[Victor Bazarov]

a0******@NOstudent.SPAMhis.se wrote:

[...]
Well, what I was thinking might be in favor of making them pointers was
that they end up on the heap, rather than the stack. And if I have a
huge honking lot of these little things, I'd rather not fill up the
stack with that.

You may be a bit confused. If you have "a huge honking lot of these
little things", they are _all_ probably on the heap, so their contents
are on the heap along with them...

V

[a02hansj]

Victor Bazarov <v.********@comacast.net> wrote:

a0******@NOstudent.SPAMhis.se wrote:

[...]
Well, what I was thinking might be in favor of making them pointers was
that they end up on the heap, rather than the stack. And if I have a
huge honking lot of these little things, I'd rather not fill up the
stack with that.

You may be a bit confused. If you have "a huge honking lot of these
little things", they are _all_ probably on the heap, so their contents
are on the heap along with them...

V

See, I didn't know that, that a pointer to a class puts the whole of the
class on the heap.

--
Hans

[Victor Bazarov]

a0******@NOstudent.SPAMhis.se wrote:

Victor Bazarov <v.********@comacast.net> wrote:

a0******@NOstudent.SPAMhis.se wrote:

[...]
Well, what I was thinking might be in favor of making them pointers was
that they end up on the heap, rather than the stack. And if I have a
huge honking lot of these little things, I'd rather not fill up the
stack with that.

You may be a bit confused. If you have "a huge honking lot of these
little things", they are _all_ probably on the heap, so their contents
are on the heap along with them...

V

See, I didn't know that, that a pointer to a class puts the whole of the
class on the heap.

I am again not sure whether you understood my point.

If you do

class vector
{
double x,y,z;
...
};

void somefunction()
{
vector avector;
}

then 'avector' and all its contents (x,y,z) are "on the stack" (as we
often refer to automatic variables).

If you do

const size_t A_LOT_OF_THEM = 1000000;

void somefunction()
{
vector *hugehonkinglot = new vector[A_LOT_OF_THEM];
}

then all vector objects are allocated in the free store ("heap") and
their contents are there too. The pointer to the vectors in that case
is not on the heap, it's an automatic variable, and as such is "on the
stack".

V

[msalters]

Karl Heinz Buchegger wrote:

In general - allocate dynamically if:
* you don't know in advance how many
* you need polymorphism and have a need to have
polymorphic objects in a container
* your class is extremely large.

* the contained member cannot or should not be declared
in the header file (common case for pimpl idiom)
* the member must outlive its initial owner or be created
earlier than the owner.