Sign in to follow this  
YellowMaple

C++ question about returning null

Recommended Posts

YellowMaple    174
Hi, I'm working on making a Shooter (SHMUP) game in OpenGL. Right now, I have a class called player that represents the player spaceship. I also have a class called Actor and a class called bullet which inherits the Actor class. In the player class, I have a function to process input from the keyboard, and would like to return a bullet object if the 'fire' key is pressed. However, if it is not pressed, I would like to return null. However, I get errors saying that cannot convert from bullet to int or something along those lines. I was able to sort of get it working using pointers, but it seems as though even if it's returning null, it's still going through the constructor for the bullet object and this slowed the game down a lot. Can anyone tell me how to simply return null in C++ without having the constructor method carried out, or can anyone suggest a better design to implementing a player ship and the bullets fired from the ship?

Share this post


Link to post
Share on other sites
Kristafarii    172
You'll have to return a pointer to the bullet object.

if (bullet_required)
return createBulletPtr();
else
return NULL;

This seems obvious, am I missing something?

Share this post


Link to post
Share on other sites
Kuladus    380
Note also that if you are going to have lots of bullets created and destroyed all the time then this method is not the best (unless you overload new) ...

However tackle this issue when and if you come across it, don't optimise prematurely!

Share this post


Link to post
Share on other sites
markr    1692
Why not have the fire method on the spaceship class, create the bullet itself then call the method / function in your object-management to add it there and then, rather than returning a pointer?

Personally what I do is have a manager "addObject" function which takes a pointer to the base class (in your case, Actor), and adds it to the list (actually, it adds it to another list, which then gets added to the main list at the end of the frame).

Mark

Share this post


Link to post
Share on other sites
someboddy    100
NULL in c/c++ is defined:
#define NULL 0
so "return NULL" is the same as "return 0", which is in.

try something like:
[source lang=c++]
bullet* checkToCreateBullet(int create)
{
if(create)
return new bullet(...);
else
return (bullet)NULL;
}

Share this post


Link to post
Share on other sites
May I suggest going from value return to using an output variable or better yet iterator.
Im guessing you have:

Buller HandlePlayerFire(void)
{
//loads of cool logic
}


as have been pointed out returning a pointer can solve this but you would still need to store the pointer somewhere remember to clean it up etc. You're probably already storing your bullets in an array/vector/list, my suggestion is to make use of the iterator concept to simply insert new bullets in the container if the player is fireing the code would then look like

template <typename OutItr>
OutItr HandlePlayerFire(OutItr dst)
{
//logic add bullet via:
*dst++ = Bullet(...);
return dst;//this can be plenty convinent
}


calling code would then be something like

HandlePlayerFire( std::back_inserter( BulletContainer));

or if you're using a plain array:

//assuming LastActiveBullet is the insertion position
LastActiveBullet = HandlePlayerFire( LastActiveBullet);

Share this post


Link to post
Share on other sites
Shadowdancer    319
Quote:
Original post by someboddy
NULL in c/c++ is defined:
#define NULL 0
so "return NULL" is the same as "return 0", which is in.


That's only true for C++. It's not that simple in C:

#undef NULL
#if defined(__cplusplus)
#define NULL 0
#else
#define NULL ((void *)0)
#endif

Share this post


Link to post
Share on other sites
furby100    102
Quote:
Original post by d000hg
Yes that's what you want.
CBullet *CreateBulletIfFire(bool isFiring)
{
if(!isFiring)
return NULL;
else
return new CBullet;
}


Warning: Not all control paths return a value.

Remove the else and you'll be fine.

Share this post


Link to post
Share on other sites
sordid    246
Quote:
Original post by furby100
Quote:
Original post by d000hg
Yes that's what you want.
CBullet *CreateBulletIfFire(bool isFiring)
{
if(!isFiring)
return NULL;
else
return new CBullet;
}


Warning: Not all control paths return a value.

Remove the else and you'll be fine.


Odd.. both control paths DO return a value. In both logical ways that comparison is evaluated, each results in a value returned. Should be no problem there..

	int *bleh(bool argh)
{
if (argh)
return NULL;
else
return new int;
}


Compiles fine under MSVC.NET, and it's the same code (substituting a primitive for an object)

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
Quote:
Original post by furby100
Quote:
Original post by d000hg
Yes that's what you want.
CBullet *CreateBulletIfFire(bool isFiring)
{
if(!isFiring)
return NULL;
else
return new CBullet;
}


Warning: Not all control paths return a value.

Remove the else and you'll be fine.


Incorrect. All control paths -DO- return a value... it's an all-inclusive set of boolean comparisons.

Share this post


Link to post
Share on other sites
Helter Skelter    332
Quote:
Original post by furby100
Quote:
Original post by d000hg
Yes that's what you want.
CBullet *CreateBulletIfFire(bool isFiring)
{
if(!isFiring)
return NULL;
else
return new CBullet;
}


Warning: Not all control paths return a value.

Remove the else and you'll be fine.




Blah! Be a man!!!!
CBullet *CreateBulletIfFire(bool isFiring)
{
return (!isFiring ? NULL : new CBullet);
}


:)

Share this post


Link to post
Share on other sites
void*    292
Quote:
Original post by Helter Skelter
Blah! Be a man!!!!
CBullet *CreateBulletIfFire(bool isFiring)
{
return (!isFiring ? NULL : new CBullet);
}


:)


why not

return isFiring ? new CBullet : NULL;


no need to use the negation operator! save the nanoseconds!

:-P

Share this post


Link to post
Share on other sites
d000hg    1199
I'd imagine it would just use the reciprocal jump operation when compiled, so it's purely an aesthetic issue. Still checking NOT(...) seems harder to me so I agree with you!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this