Re: [boost] [err] RFC

Subject: Re: [boost] [err] RFC
From: Domagoj Saric (dsaritz_at_[hidden])
Date: 2016-01-09 18:02:36

On 30.11.2015. 4:45, Gavin Lambert wrote:
> On 30/11/2015 16:18, Domagoj Šarić wrote:
>> On Fri, 27 Nov 2015 04:56:32 +0530, Gavin Lambert
>> <gavinl_at_[hidden]> wrote:
>>> It does make the behaviour a little strange for the various
>>> cases though:
<snip>
>> That's intended/by design behaviour
<snip>
> I'm not calling out the cases individually as problems, I'm trying
> to point out that the set as a whole seems inconsistent, and
> somewhat surprising with regard to "auto" and (at least for the
> original implementation) with the asserts.  Maybe I'm just being too
> nitpicky though.

Hi Gavin, thanks for all the valuable feedback and this late of a
response...
I've since fixed the issues that were brought up (notably the
asserts/sanity checks).

Could you please restate/elaborate on where do you see inconsistencies
in the design (or perhaps the idea itself)?

The problem of making auto 'less nice' is I suspect not 'fully
solveable' but it is to a 'significant' degree (e.g. by the use of the,
existing, operator* or some possible use of operator | as is done by the
Boost.Range library with its adaptors)...

ps. OT/'to whom it may concern': fixing the 'too strong assertions' 
problem (allowing multiple fallible_results to exist) and making it work 
on Android (where we still don't have even proper 'POD thread locals') 
with Clang forced me to reinvent boost::thread_specific_ptr (to avoid a 
dependency on Boost.Thread) in the process of which I found that 
Boost.Thread only asserts/'verifies' that calls to pthread_key_create() 
and pthread_setspecific() succeeded (which my fail with ENOMEM)...

-- 
"What Huxley teaches is that in the age of advanced technology,
spiritual devastation is more likely to come from an enemy with a
smiling face than from one whose countenance exudes suspicion and hate."
Neil Postman