Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

PaulCunningham

References and Pointers

This topic is 5656 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 currently using C++ to write a small game. I originally 'learned' C (i.e. skimmed very quickly through the C Programming Language) ages ago before leaning more towards C++. I'm try to unlearn certain C isms in an attempt to do the C++ thing properly. Currently I'm doing something like this...
class FSMState
{
	public:
		virtual FSMState* update(Actor* const actor) = 0;

};

class AttackingState : public FSMState
{ 
	public:
		virtual FSMState* update(Actor* const actor) {
			cout << "AttackingState::update" << endl; 
			return this;
		};
};



Would I be better off using references? - I'm asking because this seems to be the more C++ way to do things?

   
class FSMState
{
	public:
		virtual FSMState& update(Actor& actor) = 0;

};

class AttackingState : public FSMState
{ 
	public:
		virtual FSMState& update(Actor* actor) {
			cout << "AttackingState::update" << endl; 
			return *this;
		};
};
I'd use it like...
m_state = m_state->update(this); 
  
or
m_state = m_state.update(this); 
 
Are there any real difference under the hood in these 2 approaches? Does the *this statement cause any kind of performance hit? Are references more of a syntax thing to get rid of dificult to understand dereferencing code? Are the two approaches pretty much interchangeable? Cheers, Paul Cunningham EDIT: Fixed the code tag. [edited by - PaulCunningham on June 19, 2003 8:26:32 AM]

Share this post


Link to post
Share on other sites
Advertisement
They are interchangeable, it's just however you prefer doing it. There is no performance difference that I know of, as they both are just sending a pointer to a memory address, it's just different syntax. I beleive the reference was added to the C++ language, and isn't valid in C, so that would make it a more C++ way to do it I guess. I think the reason they did this, was so people didn't get confused with passing pointers to arrays, and pointers to single objects around.


void Test(Actor* const actor)
{
cout << "Lets error this thing out!" << actor[2].CurState;
}


What's to stop some moron from using it as an array instead of a pointer to a single element? Of course I know you wouldn't, but when sharing code, using the reference is much safer, because they won't have to guess if it's supposed to be an array or a pointer to a single object.

Also, there are a few more syntactical ways to do the same thing

actor->CurState;
actor[0].CurState;
*actor.CurState;
(*actor).CurState;


These are just a few examples on how people write the code that does the exact same thing, different people have different coding styles. I would mostly stick to refrences though. I also come from a C background, but I stick to references in C++ unless I'm passing an array, it just makes more sense .


--- Edit ---
Ps. Edit your post, and fix your [ /code ] tag!

[edited by - Ready4Dis on June 19, 2003 7:32:48 AM]

Share this post


Link to post
Share on other sites
References and pointers are not interchangeable!

The reason is that you can have a NULL pointer but you cannot have a NULL reference.

Beginners and experts will find answers here.

Share this post


Link to post
Share on other sites
quote:
Original post by Mathematix
References and pointers are not interchangeable!

The reason is that you can have a NULL pointer but you cannot have a NULL reference.

Beginners and experts will find answers here.



Sure you can:

void Test(Actor &a)
{
if (&a==NULL)
{
}
}

Test(*(Actor*)NULL); //Just passed a NULL in

Why you would want to is beyond me, but it IS possible . Also, there is almost no reason to pass a NULL into ANY function, and in this case, he is talking about passing objects that ARE already valid into the function, in which case, they are 100% interchangeable.

--- Edit ---
Let me be a tiny bit more specific... using pointers is a good idea with dynamically allocated memory in some cases, if you want to check for NULL in the function, BUT, there really isn't a very good reason to do this in most cases (yes, there are some cases where it's the most efficient, and easiest to implement way of doing it, but in those cases, it's normally not just a SINGLE element you're passing, but an array, in which case I said to use the pointers).

[edited by - Ready4Dis on June 19, 2003 7:44:57 AM]

Share this post


Link to post
Share on other sites
Null references are the work of the devil!
Some little comment on the references, they make it possible to have some of those nice and wonderful operators in our lovely classes ;p

Share this post


Link to post
Share on other sites
quote:
Original post by Ready4Dis

void Test(Actor &a)
{
if (&a==NULL)
{
}
}

Test(*(Actor*)NULL); //Just passed a NULL in



Only "works", if Test's argument is a reference to a const (as NULL is a constant)
void Test(const Actor & a);  


or if the function is called like
Actor * p = 0;
Test(*p);


as p is not a constant.

In fact, *noone* would ever call a function with '*(Actor*)NULL'. But wait. Never they never. There *might* be a genious out there who does *g*

Regards,
VizOne

[edited by - VizOne on June 19, 2003 8:00:32 AM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Remember references must be assigned when they are defined, so

m_state = m_state.update(this);

would become

FSMState& m_state = m_state.update(this);


But this would be impossible if your m_state is a member of a class.

In some cases passing NULL can be useful (at least as a default), in other cases you may want to enforce a valid object so a reference is used.

As for NULL references, the programmer who wrote that deserves everything exception that they get

Share this post


Link to post
Share on other sites
As the AP said I''d need to initialise the reference (it is a class member) which also gives me a little problem.

m_state'' : must be initialized in constructor base/member initializer list

this is because my class is abstract base so I thought I could delay initialisation until derived classes.

e.g.


class Actor {

public:
Actor() {};

virtual void update () {
m_state = m_state.update(this);
};

virtual int temp() = 0; //force abstract


protected:
FSMState& m_state;

};

class Alien: public Actor {

public:
Alien() : m_state(Singleton<SpawnState>::instance()) {};

virtual int temp();
};


Apparently not though - is there a way arround this?

Cheers,
Paul Cunningham

Share this post


Link to post
Share on other sites
quote:
Original post by Ready4Dis
Sure you can:

void Test(Actor &a)
{
if (&a==NULL)
{
}
}

Test(*(Actor*)NULL); //Just passed a NULL in

Why you would want to is beyond me, but it IS possible . Also, there is almost no reason to pass a NULL into ANY function, and in this case, he is talking about passing objects that ARE already valid into the function, in which case, they are 100% interchangeable.

--- Edit ---
Let me be a tiny bit more specific... using pointers is a good idea with dynamically allocated memory in some cases, if you want to check for NULL in the function, BUT, there really isn''t a very good reason to do this in most cases (yes, there are some cases where it''s the most efficient, and easiest to implement way of doing it, but in those cases, it''s normally not just a SINGLE element you''re passing, but an array, in which case I said to use the pointers).

[edited by - Ready4Dis on June 19, 2003 7:44:57 AM]


Reinterpretations (casts) don''t count! ;D



Beginners and experts will find answers here.

Share this post


Link to post
Share on other sites

  • 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!