Quote:Original post by GanonPhantom
Ok, so im building my own Safe/Smart Point persay, and ive been looking into how to handle all of my Null Pointers.

C++? boost::shared_ptr [wink]

Quote:
Right now, i think I will take the Try, Catch, Throw solution. But, i want a second opinion as to what i can do to "get out of there" when i have a null/corrupt pointer.

What do you mean, what's wrong with a null pointer? Something like this?

bar(ptr)    if (ptr is null)        panic();    ptr->foo(9001); /*lol*/

It depends on the situation. You might want to just log and exit, or throw an exception (for example, if the renderer encounters a runtime error, throw an std::runtime_error), etc.

Quote:Original post by GanonPhantom

Sorry, i dont want to use any boost libraries in my projects, as it will be open source sooner or later, and i dont want to have to make people download/check-out alot of code.

Any decent C++ programmer should already have Boost ready to go [grin]. Really, though, it's not "a lot of code." Boost has been rigorously tested for a very long time, it'll save you a lot of development time compared to the time it takes you to roll your own version and debug it well enough to get rid of all of the bugs.

Quote:
Plus, its also a learning experience.

That's perfectly fine, if it was only a learning experience.

Quote:
With the "Whats wrong with a NULL pointer" thing, its a problem when you try to call a function from a pointer that points to 0x00000000 (or sometimes the debugger shows 0x0C0C0C0C) [wink].

Well, yeah, and thus, I replied:

Quote:
It depends on the situation. You might want to just log and exit, or throw an exception (for example, if the renderer encounters a runtime error, throw an std::runtime_error), etc.

Quote:Original post by GanonPhantom
Whats wrong with managing stuff myself, it only makes me smarter and gives me a more inside scoop on how things are handled which will allow me to better structure my program in the long-run.

Reinventing the wheel does not make you smart. Though I'm bad at proving these things, so I'll stop here and let someone else do the explaining.

No one is saying you should blindly use boost::shared_ptr without understanding how it is implemented. In fact, understanding how it is implemented is crucial in avoiding the reference loops that can cause memory leaks.

As for reinventing the wheel, there may be certain cases where you can improve on what has gone before. IMO a C++ smart pointer class is not such a case. They are pretty much infrastructure now, and should really be in the standard library. AFAIK, boost's smart_ptr interface is what will be used for the next C++ standard library, which will include a smart pointer (it may already be available in a suppementary namespace in your standard library). You could probably download a reasonably well used and tested implementation of some smart pointer interface from a number of sources, rather than spend valuable developer time doing it yourself.

As for your questions, I would use assert() for situations that should never happen (e.g. calling operator*() or operator->() on a null smart pointer). Exceptions really should only be used for situations where it is reasonable to recover. It is context dependant, but calling such an operator on a null smart pointer is usually a serious logic error and the programs state may be undefined no matter what you do.

I wouldn't go into the NullObject idea. While I can think of maybe a few domain specific situations where it might have merit - it isn't really a general purpose solution to the problem.

Quote:Original post by GanonPhantom
ok, thx for the reply rip-off :)

For assert(), is there a way to make it not pop up with a message box, and continue execution (to the front of the thread loop)? As this is a Server Emulator, and stopping the execution while there are hundreds of people are online isnt really ideal.

Thx for the formal reply thought,
GanonPhantom

assert() is for situations that are never supposed to happen, it exists only in debug mode. It's not meant to continue executions - that's what logging is for. Don't log inside the pointer; like I said, check the point if it's null in the block of code that uses it, and if so, act appropriately.