Re: naked pointer vs boost::shared_ptr<T>
On Mar 3, 12:24 pm, Al <t...@haik.us> wrote:
James Kanze wrote:
<snip>
Alternatively, I've been experimenting with changing some existing raw
pointers into either:
CheckedPointer<T> or
OptionalPointer<T>
Where the former requires (and asserts) that its pointer never be null,
and the latter allows a null pointer, but asserts that a null pointer is
never dereferenced -- any feedback on this idea is appreciated :).
I don't see much advantage in the second; all of the systems I
work on fail when a null pointer is dereferenced anyway. The
former might be interesting in some contexts, although the name
is a little vague; maybe NonNullPointer<T>?
Yeah, the names need a little work. Regarding the advantage, there are a
couple for me. First, I'm paranoid in that the a null dereference is, I
believe, undefined behavior, so that failure is not guaranteed.
Yes. It depends on your target platforms. I currently write
software for large scale servers, so I can "portably" count on a
core dump when I dereference a null pointer (just as I
"portably" count on pthread_mutex_t, etc.).
In
addition, for debugging purposes, I've found it easier to manage using
these.
What's the difference between an assertion failure and what
happens if you actually dereference the pointer?
For instance, you can set a single permanent breakpoint, and you can
avoid the mess that would have happened otherwise.
Except that the breakpoint is only present when you're running
under the debugger, which is rarely the case, and "the mess that
would have happened otherwise" is a core dump---precisely what I
want to do a post-mortem.
Finally, the stack in
the debugger is usually cleaner because the error didn't go any further.
I find the stack cleaner when I get the core dump: I don't have
the extra entries for the functions called from assert. (The
difference is marginal, however.)
One other potential use is to provide a graceful exit / exception for
the program in the event the error occurs, but I haven't done this yet.
I'm not sure you want (or can have) a graceful exit; you want
that core dump, to find out exactly what happened.
The issues may be different in shrink wrapped software, however,
where you can't access the core dump anyway.
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]