Boost logo

Boost :

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
> 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'/ 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: 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 

Boost list run by bdawes at, gregod at, cpdaniel at, john at