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