//! returns the axis aligned bounding box of this node
const core::aabbox3d<f32>& CSceneManager::getBoundingBox() const
{
#ifdef _DEBUG
os::Warning::print("Bounding Box of Scene Manager wanted.");
_asm int 3;
#endif
// should never be used.
return *((core::aabbox3d<f32>*)0);
}
Returning a de-referenced NULL
Just found this little code snippet in the source code of irrlicht 0.1
Now, wouldn't the return cause really bad things to happen since you are basically de-referencing a NULL pointer?
Dereferencing something involves actually using it for reading or writing to it. Here it's just a casted NULL pointer that is returned - but not used.
As it's irrlicht 0.1 and there's a comment above the return statement 'should never be used' I'm guessing this method was just a place-holder until the author got round to actually writing the real version. As to why it returns a de-referenced null pointer it has to return a core::aabbox3d<f32>& and that's probably the simplest way to generate something to return. Also I think the actual return statement would execute without problems as a reference is basically a pointer in disguise. Problems would occur when you attempt to use the returned reference. Officially in the C++ standard the effect is almost certainly undefined though so pretty much anything could happen.
That code is evil.
Alternative suggestions for stubbed functions:
throw std::runtime_error( "function foo() unimplemented" );
assert( ! "function foo() unimplemented" );
exit( -1 );
Alternative suggestions for stubbed functions:
throw std::runtime_error( "function foo() unimplemented" );
assert( ! "function foo() unimplemented" );
exit( -1 );
Quote:Original post by Anonymous Poster
Dereferencing something involves actually using it for reading or writing to it. Here it's just a casted NULL pointer that is returned - but not used.
This code is an abomination. He's creating a null reference. People don't expect references to be invalid like that. Sure, returning it will work, but any attempt to use it will blow up. Have fun with that.
Quote:and that's probably the simplest way to generate something to return.
If you look at the debugging string, it's trying to get the bounding box of an "abstract" object which doesn't have one. Why does that class possess such a member function? If it's to keep the class hierarchy simple, this is the right place to throw an exception. Deliberately tossing around null references is moronic. References aren't intended to be used as pointers.
i think he simply has to return "something" to make compiler happy, and at this moment the class doesn't do anything other than throwing exception with "int 3".
But yes it's better to throw real exception.
Also i think it is bad idea to return reference to bounding box in first place.
But yes it's better to throw real exception.
Also i think it is bad idea to return reference to bounding box in first place.
Of course, you do have to consider the fact that The Code Will Never Be Reached. If the function is entered AT ALL, it's an error - that's why theres a breakpoint in there. The only way to get to it is if the programmer enters the debugger.
Quote:Original post by Deyja
Of course, you do have to consider the fact that The Code Will Never Be Reached. If the function is entered AT ALL, it's an error - that's why theres a breakpoint in there. The only way to get to it is if the programmer enters the debugger.
nope. If _DEBUG is not defined, you get null reference.
i think in a situation like this one you could also convince the compiler to shut up using __assure(false); .... evil code, i agree.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement