A Pointer, or a Reference ?

Ah, one of the holy-war subjects. =)

Operator overloading, at least in such a way that your custom type acts just like a built-in type, is impossible without using references.

Pointers _can_ act like a tri-state, in that if you pass a NULL pointer into a function, the function can take that to mean "don''t do that part of the function". Example:
getDateAndTime (Date *pDate, Time *pTime);
The function can be written so that if pDate == NULL, the date is not retrieved; only the time is. This is unwieldy to do with references (I used to say impossible, but some compilers seem to allow enormous amounts of tomfoolery on this subject).

I prefer using references when the object is a required argument, and the object is required to exist (e.g. passing in a container that is to be appended-to). However, some people absolutely despise functions that take references; their point of view is that unless they pass the address of their data, they should be sure that the function can''t change the data. Of course this is what const is for, but some people don''t like checking function declarations. Do not underestimate how uncomfortable reference arguments can make some people.

A pointer can change what adress it points too while a reference refer to the actual object itself.

I think it''s recommended to use pointers when you will alter the object in anyway inside a method or a function.

Pointers can also be checked if they''re NULL or not.

But for Collision Detection for example I think references would be the way to go.


bool Collision(const Sprite& sprite1, const Sprite& sprite2)
{
// blabla
return true;
}


One way to think about it is if it''s a const argument and you don''t need to check for a NULL pointer use references.

In the case of operator overloading ppl most always use references in any case.

Something to keep in mind.

References are qualified, pointers are not.

A reference will always reference something of its type.
A pointer is just an arbitrary memory address that may or not may not point to its type.



D.V.

Carpe Diem

Because your pointer may have never been allocated to anything, or you may have accidently changed what it pointed to, or something along those lines. A reference always refers to what it''s supposed to, so while a pointer may not mean what you want it to, a reference always will.

Just a little way to ensure that what''s going to the function is what you want.

Yeah, you may not explicitly type:

DoSomething(NULL) 

but it''s quite likely you will have something like

Entity* something = GetLastEntity();
DoSomething(something); 

...and GetLastEntity() may return NULL if it couldn''t find something. So in this case, DoSomething needs to check that it hasn''t been given a NULL pointer.

I would prefer to do something like this:

Entity* something = GetLastEntity();
if (something)
    DoSomething(*something); 

...where DoSomething now takes a reference rather than a pointer. Generally I use references as parameters and pointers as return values, since I nearly always want parameters to be valid (to save on putting NULL checks inside all the client code) but often I want to be able to return NULL from a function.

But the general rule for me is again: references wherever possible, pointers everywhere else.

Well, this wasn''t as cut and dry as I expected.

I''d like to thank everyone for your responses to
this question. I now have an idea of how I''ll use
these pointers, and references. But I can see there
certainly is a difference in opinion. The arguments
on both sides are very good. I found myself being
swayed in one direction, then to the other. But I
now believe there is a balance in there somewhere.

Thank You,

Guy