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@compacsort.com> 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