Re: [boost] [review] Shmem

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2006-02-16 11:58:48

Hi David,

> But it's not possible to tell is that someone has passed you something
> nasty when somebody else uses no_throw and you're just getting a
> reference to the object.  That's my whole point.  Strong invariants
> make it possible to develop code separately without adding lots of
> nasty preconditions everywhere to "ensure" that nobody has given you
> something nasty.

Well, if the programmer never checks the error of the construction 
function when he is explicitly requesting a no-throw, the programmer is 
the problem. So if the programmer requests a new[](std::nothrow) and 
does not check if the returned pointer is not null, and you receive a 
null pointer, you have the same problem.

>> It seems to me that this should be good enough even if it's not
>> ideal.
> 
> It's not really much better than having a default ctor that doesn't
> initialize the object.  The problem doesn't occur at the point of
> construction; it occurs everywhere else in the program.  If you make
> it easy for the guy doing construction to use a 2-phase approach, you
> make reasoning about code much more difficult for everyone else, and
> you either complicate their preconditions or you force them into
> checking for initialization and throwing exceptions.  It's a mess.

But there is no 2-phase construction: You can only initialize the object 
in the constructor and there is no open/create function. It's one-phase. 
But if the programmer does not check the error when he passes the 
std::nothrow extra argument (so we suppose the programmer is requesting 
a manual error check), then it's obvious that that object will be 
ill-formed. There is always a way to crash a program. No doubt.

My only concern is that code reuse from embedded systems that don't use 
exceptions (mainly because of the space overhead and the lack of 
predictability when the exception is thrown) won't be possible. And this 
happens many times. Maybe in the Shmem case it won't be so usual 
(although there are multi-process real-time Boost supported operating 
systems like QNX). But in multi-threaded embedded applications where 
almost always exceptions and RTTI are disabled to gain space you surely 
need a threading library with an alternative with no exceptions where 
code reuse should be possible. And C++ is becoming more and more 
important in those systems, replacing C programming. Just my 2 cents.

But I accept the boosters verdict: pure RAII only.

Regards,

Ion