Subject: Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)
From: degski (degski_at_[hidden])
Date: 2018-01-30 23:12:46
I'll be short and add my comments to ED's review...
In general, I would like to state that if there is so much to say about
something relatively simple, red flags are up.
On 30 January 2018 at 15:07, Emil Dotchevski via Boost <
> It is wise to take the author seriously on his intentions to evolve...
This, I feel, is related to what's raised below: " It seems like Outcome
wants to stay away from Boost."
> There is a reason why in C libraries the default error reporting mechanism
> is to return int, even
> though the language does permit programmers to return structs, which would
> be more flexible.
Speaking of interoperability, it is especially tricky to report errors from
> C-style callbacks. This would be nice to support because C++ exceptions are
> off-limits in this case, yet it is sometimes desirable to communicate
> user-specific information across the third-party C callback mechanism (this
> is sometimes supported by a void * user data pointer, but that is not
> always the case).
C is a dirty word...
> Further, I disagree with the motivation to avoid using exceptions to begin
> with. The supplied decision matrix, I think, does not reflect reality. In
> my experience, the decision matrix to use C++ exceptions vs. something else
> is much simpler: "Do you hate exceptions?" No => use exceptions, Yes => use
> something else, because exceptions suck.
Yes, exception handling has overhead. No, you can't afford this overhead in
> every last corner of a complex program, but yes, you can afford it in
And it's builtin...
And this is trivially true: if exception handling causes problems in some
> subsystem, the solution is to hide that subsystem behind a C-style API and
> compile only that subsystem with exception handling disabled.
Or write some defensive code to make sure a potential problem doesn't need
to become an exception...
This is important, as it
> is typical for programmers coming from other languages to be shocked by
> various C++ language features, and this should not be confused with
> problems in the C++ language specification.
I'm shocked, coming from C, that simple things have to become so complex...
- What is your evaluation of the implementation?
> Lack of C++11 support could be problematic. The use of macros to
> disambiguate namespace is cumbersome. Overall the library relies heavily on
> macros, which is not a good thing for a C++ library.
This seems so weird (and contradictory), we're using advanced C++, but
still rely on C concepts (PP) to make it work, ugly...
> It seems like Outcome wants to stay away from Boost.
To me it seems Outcome wants to be able to break with Boost at any moment,
and that safety-net is already builtin...
- Are you knowledgeable about the problem domain?
I'm not, I'm just a simple guy...
> - Do you think the library should be accepted as a Boost library?
> The library should be rejected.
+1, a lot of mental m.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk