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: Nevin Liber (nevin_at_[hidden])
Date: 2013-10-08 15:22:06

On 8 October 2013 13:17, Thorsten Ottosen <thorsten.ottosen_at_[hidden]>wrote:

>
> We are indeed going in circles. I can respect that some people don't want
> the overhead of the runtime check. I can also respect that people don't
> want to take down the whole server because of a bug in some subsystem.

Except you can't know if it is a bug in a subsystem or somewhere else.  If
you know the bug is from the subsystem, why did you put the bug in?  And if
you don't know the root cause of the bug, how can you possibly know the
effect?  All you've detected is a symptom.  The rest of the "analysis" is
nothing more than wishful thinking.

> We just need to find a way to give both camps what they want, since both a
> valid use-cases.
>

No, we don't.  Decide if your API has preconditions or not.  For instance,
the real difference between vector::operator[] and vector::at() is that the
former has a precondition while the latter does not.  If you define the
behavior, it isn't a precondition, precisely because you are explicitly
allowing it, and a correct program can call it with any value it likes.

This is, of course, one of the many hard parts of library design.  Make
strong choices.  Making it "configurable" whether or not something is a
precondition is a weak choice.

This, of course, doesn't mean you can't be friendlier if/when you detect a
precondition violation in debug mode.  But be very clear that it is a
precondition violation resulting in undefined behavior.
-- 
 Nevin ":-)" Liber  <mailto:nevin_at_[hidden]>  [phone]