Re: [boost] [system][filesystem v3] Question abouterror_codearguments

Subject: Re: [boost] [system][filesystem v3] Question abouterror_codearguments
From: Domagoj Saric (dsaritz_at_[hidden])
Date: 2009-11-01 18:03:54

"Gottlob Frege" <gottlobfrege_at_[hidden]> wrote in message 
news:97ffb310910302049u46d5cbddm557fb47bfbd663da_at_mail.gmail.com...
> On Wed, Oct 28, 2009 at 6:46 PM, Domagoj Saric <dsaritz_at_[hidden]> wrote:
>> i mentioned the latter 'issue' already in the first post...
>> generally both points seem to me like non-issues because they cannot become
>> issues unintentionally...
>> both can come into play _only_ if the user converts the temporary return 
>> object
>> into a local scoped object/variable...which, as far as i know, you cannot do
>> 'by accident'/unintentionally...you have to be verbose about it...(although,
>> ironically the new auto makes it easier for you to do "the wrong 
>> thing"...but
>> still not easy enough that you can do it by a 'non conscious mistake')...
>>
>
> bool diff(file srcA, file srcB, file output)
> {
>   // get our files ready...
>   error_code srcA_err = file_open(srcA);
>   error_code srcB_err = file_open(srcB);
>   error_code out_err = file_open(output);
>
>   if (srcA_err || srcB_err || out_err) // check for errors
>      return false;
>
>   // do the diff...
>
>   return true;
> }
>
> If srcA_err is true, then srcB_err and out_err aren't checked.  On
> function exit, out_err throws on destruction, srcB_err throws on
> destruction during stack unwinding.  (I think.)
>
> So that took a bit of thought for me to come up with, but the code
> doesn't look completely unreasonable, does it?
>
> Basically, you never want more than one actual error_code to exist at
> a time (per thread).  Temporary copies would be OK (should be moveable
> anyhow, or ref counted).  This could be checked for in the debug
> build.

true...a good "find" ;)
sure we could argue that this is "non-idiomatic" usage...but still, as you 
said, it is not "completely unreasonable" so it should also work correctly...

there are two ways we could achieve this:
...one is to "smarten" the do_throw() function (i wrote about in other posts) 
to first do the "if( !std::uncaught_exception() )" check before doing the 
actual throw (this is, imho, safe and "non-evil" which i shall argue in a 
response to emil)...

...the other would require some sort of support from the compiler or some 
template/library trick to "forbid" (cause a compile error) creating a 
"smart_error_code<>" as anything other than a temporary and likewise forbid 
converting it to anything else but a temporary object...from a library POV 
perhaps this could be done so that returned objects are not actually 
"smart_error_code<>s" but some wrapper/different template instantiation 
"detail::temporary_smart_error_code<>" that the user does not have "legal" 
access to (its name, type and location are not defined by the standard) but, if 
one needs/wants to, can assign it (using move semantics) to a "proper" 
"smart_error_code<>"...and this assignment would turn off the "after throw" 
feature...the local scoped object would now only assert that it was inspected 
in its destructor...(and still provide a public do_throw() - like function so 
that the user can still choose to throw if he/she has no means to locally deal 
with the error)...

-- 
 "That men do not learn very much from the lessons of history is the most
important of all the lessons of history."
 Aldous Huxley