Re: [boost] Looking for thoughts on a new smart pointer: shared_ptr_nonnull

Subject: Re: [boost] Looking for thoughts on a new smart pointer: shared_ptr_nonnull
From: Pete Bartlett (pete_at_[hidden])
Date: 2013-10-05 16:30:54

Rob Stewart:
>If you violate a precondition, and the function scribbles on memory, for
example, what do you >know about the state of your system?  Can you do
anything safely?  Everything you do from that >time may be wrong, despite
your hopes to the contrary.

I think this is the absolute crux of it, for me. So often I hear "if XXX
happens then all bets are off, there's nothing better than going to the
command line, directly to the command line, do not pass go, do not collect
$200." 

But my real-life experience is just not like that. What really happens in
practice is that some under pressure programmer has forgotten the one code
path that means p is NULL and so we can't construct a Widget. That's what I
know about the state of my program, that I can't construct a Widget when I
really want to. So I throw sufficiently far out of the program until it
isn't necessary to have a Widget. And there's always some layer of the
program (even it is the end of main) where that's the case. 

To give a concrete example, suppose I want to carry out 1,000,000
"simulations" of some sort that take all night to run. E.g. the simulations
returns a number and the output of my program is some statistics about those
numbers (e.g. the mean). The simulations are defined by some scenario
description language that gets parsed. In 50 of the simulations, those
definitions mean I go down a code path that has the bug. In the other
999,950 definitions, I get the right answer. If I assert, then I lose all
information about all scenarios. If I throw, I get all the information I
need about 999,950 scenarios, and an error log telling me that a program bug
needs to be fixed before the other 50 can be evaluated. The latter is, in
practice, much more useful.

By "doctrine", I was trying to invoke some thing like "established best
practice of the C++ community at large". In every other case I can think of,
learning about an established best practice has improved the programs I
contribute to. But the assert thing I still don't really believe and I've
known about it for 10 years now, so I thought I'd mention it despite
dragging things off topic - sorry for that.

Pete