Quantcast

[review] Review of Outcome (starts Fri-19-May)

Next Topic
 
classic Classic list List threaded Threaded
48 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
Niall Douglas wrote:
> > What does Outcome have to do with Boost.Thread?
> > https://github.com/ned14/boost.outcome/blob/master/include/boost/outcome/v1.0/config.hpp#L63
>
> It's stale. I didn't want to invest the effort of removing it until the
> review decides what form they want to accept Outcome in, if at all.

It creates a bit of a chicken and egg issue because the reviewer's decision
may well depend on the form you submit. Although you have a point in
principle.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Niall Douglas wrote:
> > In the event the library is accepted, what will the contents of the
> > repository boostorg/outcome be, and what will end up in the Boost
> > release under libs/outcome?
>
> That depends on what conditions the review manager places on acceptance,
> if acceptance is recommended.

Yes of course. My question was what you intend to happen.

> As I've mentioned before, during build we assemble a single file include
> of all the dependencies, including those parts of boost-lite needed. There
> is therefore no strict need to ship boost-lite in any boostorg repo, which
> is good as I believe boostorg currently doesn't support project level
> subrepos.

This would only work if I use boost/outcome/outcome_v1.0.hpp, right? The
headers in v1.0/ do not compile without boost-lite.

> To be honest, I don't think it hugely important how we get Outcome into
> boostorg,

An interesting position. I, however, in order to decide between Yes and No,
need to know what, precisely, will happen on Yes.

Of course I could say Yes if you do such and so, otherwise No, but it's good
to know how you see things and what's your intent.

> > As I already asked, will boostorg/outcome be the primary source
> > repository for Boost.Outcome? If there is a PR submitted against
> > boostorg/outcome, what steps will need to be performed in order for that
> > PR to become integrated into the Outcome code base?
>
> I'd prefer not a script generated boostorg/outcome repo, it makes
> maintenance harder.

I'm not sure I understand. If you prefer not a script-generated
boostorg/outcome repo, what do you prefer?


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
>> To be honest, I don't think it hugely important how we get Outcome
>> into boostorg,
>
> An interesting position. I, however, in order to decide between Yes and
> No, need to know what, precisely, will happen on Yes.
>
> Of course I could say Yes if you do such and so, otherwise No, but it's
> good to know how you see things and what's your intent.

My opinion there is that the documentation, code, design and
implementation are what is being reviewed. Build stuff and test stuff
and maintenance stuff are of course important, but that's *process*
stuff, it's secondary in importance relatively speaking. I mean,
basically build, test and maintenance stuff is on me to get right, else
I will spend enormous amount of my very limited free time on it. And I
am highly unlikely to choose that situation.

It is possible that the review places such onerous conditions on
admission that I cannot see a path to take this codebase into Boost
without completely rewriting it from scratch. I hope not, that would be
a big ask.

>> > As I already asked, will boostorg/outcome be the primary source >
>> repository for Boost.Outcome? If there is a PR submitted against >
>> boostorg/outcome, what steps will need to be performed in order for
>> that > PR to become integrated into the Outcome code base?
>>
>> I'd prefer not a script generated boostorg/outcome repo, it makes
>> maintenance harder.
>
> I'm not sure I understand. If you prefer not a script-generated
> boostorg/outcome repo, what do you prefer?

There's script generated within my build system. That's okay, it's
already doing that, indeed that's going to get much worse with issue #25.

Then there's script generated whereby a new git repo is one-way
synthesised by cron script from another git repo (like ASIO). I'd prefer
not to have to do this.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
Niall Douglas wrote:
> > I'm not sure I understand. If you prefer not a script-generated
> > boostorg/outcome repo, what do you prefer?
>
> There's script generated within my build system. That's okay, it's already
> doing that, indeed that's going to get much worse with issue #25.
>
> Then there's script generated whereby a new git repo is one-way
> synthesised by cron script from another git repo (like ASIO). I'd prefer
> not to have to do this.

I still don't understand. Let me describe what I would like to see, and
you'll tell me if you see things the same way.

What I'd prefer to see is, in boostorg/outcome:include/boost/outcome, in
addition to the outcome_v1.0.hpp header as currently generated, an
outcome.hpp file that includes the headers in v1.0, as it currently does
when BOOST_OUTCOME_DISABLE_PREPROCESSED_INTERFACE_FILE is defined. I also
would like this to work without boost-lite, pcpp, gsl-lite being present at
all in the boostorg/outcome repo (or on the user's system).

Furthermore, when someone issues a pull request against
boostorg/outcome:include/boost/outcome/v1.0/something.hpp, I'd like to see
this pull request kicking off a travis build as we're now used to, with this
travis build actually testing Outcome with the pull request applied.

Does this make sense?


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
> I still don't understand. Let me describe what I would like to see, and
> you'll tell me if you see things the same way.
>
> What I'd prefer to see is, in boostorg/outcome:include/boost/outcome, in
> addition to the outcome_v1.0.hpp header as currently generated, an
> outcome.hpp file that includes the headers in v1.0, as it currently does
> when BOOST_OUTCOME_DISABLE_PREPROCESSED_INTERFACE_FILE is defined. I
> also would like this to work without boost-lite, pcpp, gsl-lite being
> present at all in the boostorg/outcome repo (or on the user's system).
>
> Furthermore, when someone issues a pull request against
> boostorg/outcome:include/boost/outcome/v1.0/something.hpp, I'd like to
> see this pull request kicking off a travis build as we're now used to,
> with this travis build actually testing Outcome with the pull request
> applied.
>
> Does this make sense?

I appreciate your wishes in the above. I should point out that Outcome
already is tested per commit by Travis and Appveyor, and it keeps a
history at CDash: http://my.cdash.org/index.php?project=Boost.Outcome

But it is very hard for me to be more concrete at the present time. Most
of the dependency of Outcome on boost-lite is soft, e.g.
BOOSTLITE_CONSTEXPR <=> BOOST_CXX14_CONSTEXPR, Boost-lite lightweight
unit test <=> Boost.Test and so on. But some, especially
error_code_extended's use of boost-lite's ringbuffer_log is hard.

If reviewers want what I've done to achieve error_code_extended's static
storage removed entirely, that would remove much of the hard dependency
on boost-lite and a macro layer could rebind the boost-lite macros etc
to Boost ones. In this situation, boost-lite goes away in the boostorg
repo, otherwise the repos look identical.

If on the other hand people like the static storage, one would really
rather keep boost-lite in the Outcome repo because bug fixes to there
fix lots of other libraries too, and ringbuffer_log is very heavily used
by all my libraries. I being the person with the maintenance load here
will do whatever I think makes my life easiest. How the library is
internally organised I don't think a concern for the end user unless it
negatively affects them.

Similarly, if people like the cmake build with all the fancy stuff like
automatic C++ Modules, you need boost-lite in there for that. If
Boost.Build is felt sufficient, then you don't need it.

Again, I'd emphasise that boost-lite has no interaction with Boost or
any other code. It is a 100% ideal C++ 14 citizen, right down to ABI
permuting to ensure mixed versions do not collide. Nobody will ever need
to care it's there under the bonnet as an internal helper library.

And finally, I do intend to keep Outcome working completely independent
of Boost. The vast majority of my user base explicitly do not want a
Boost dependency. You'll have noticed the same with Hana.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
Niall Douglas wrote:

> And finally, I do intend to keep Outcome working completely independent of
> Boost. The vast majority of my user base explicitly do not want a Boost
> dependency.

The vast majority of your user base may change if your library is accepted.
It almost certainly will.

Not wanting to depend on Boost is understandable. Our common infrastructure
however is not just a whim of ours, it's a service to Boost users. Going
through BOOST_ASSERT and BOOST_THROW_EXCEPTION instead of rolling your own
is more convenient for people who have already configured BOOST_ASSERT and
BOOST_THROW_EXCEPTION to do what they want them to do and would rather not
repeat that exercise for every new library, however wonderful.

Similarly, once we get the kinks out of Boost.Stacktrace, it might be better
to use that instead of #including <windows.h>.

All that's not strictly required for acceptance, in principle; neither is
using Boost.Config instead of rolling your own. And yet.

Regarding the ring buffer, I agree that it adds value. But it also adds
complexity. There's an argument to be made for result/outcome classes that
simply store std::error_code without all the bells and whistles, and provide
an optional hook to which the user can attach the ring buffer if needed.

You already have a macro-based hook for that, although I'm thinking more of
a callback.

Finally, you don't even need to macro-bind to std::error_code. Inspired by
Outcome, I wrote a pull request for Boost.System which makes the Boost
error_category, error_code and error_condition convertible to the standard
ones, so you can just store std::error_code and be done with it.

https://github.com/boostorg/system/pull/16


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
On Sat, May 20, 2017 at 3:47 PM, Peter Dimov via Boost <
[hidden email]> wrote:

> Niall Douglas wrote:
>
> And finally, I do intend to keep Outcome working completely independent of
>> Boost. The vast majority of my user base explicitly do not want a Boost
>> dependency.
>>
>
> The vast majority of your user base may change if your library is
> accepted. It almost certainly will.
>
> Not wanting to depend on Boost is understandable. Our common
> infrastructure however is not just a whim of ours, it's a service to Boost
> users. Going through BOOST_ASSERT and BOOST_THROW_EXCEPTION instead of
> rolling your own is more convenient for people who have already configured
> BOOST_ASSERT and BOOST_THROW_EXCEPTION to do what they want them to do and
> would rather not repeat that exercise for every new library, however
> wonderful.
>

It is possible to make such use of Boost macros the default while allowing
people who don't want to depend on other Boost libraries to opt-out.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
>> And finally, I do intend to keep Outcome working completely
>> independent of Boost. The vast majority of my user base explicitly do
>> not want a Boost dependency.
>
> The vast majority of your user base may change if your library is
> accepted. It almost certainly will.

I would still expect a vast majority to not want a Boost dependency.
People want C++ 14 libraries to use the C++ 14 STL, not Boost, though
*optional* non-default usage of Boost stuff appears to be popular.

> Not wanting to depend on Boost is understandable. Our common
> infrastructure however is not just a whim of ours, it's a service to
> Boost users. Going through BOOST_ASSERT and BOOST_THROW_EXCEPTION
> instead of rolling your own is more convenient for people who have
> already configured BOOST_ASSERT and BOOST_THROW_EXCEPTION to do what
> they want them to do and would rather not repeat that exercise for every
> new library, however wonderful.

Outcome only ever throws an exception via a macro. It can be customised.
If reviewers wish it, we can have the default use BOOST_THROW_EXCEPTION.

> Similarly, once we get the kinks out of Boost.Stacktrace, it might be
> better to use that instead of #including <windows.h>.

Including Outcome does not include <windows.h>, except on winclang
because winclang won't compile my win32 namespace anti-collision hack
which MSVC will.

The stack trace optionally collected by error_code_extended is
completely standard and can be fed to Boost.Stacktrace, or to any other
stack trace library. The default printer provided by Outcome is
rudimentary, but sufficient. I personally feed the addresses printed to
addr2line by hand when I need to, it works. I would be very open to
using Boost.Stacktrace instead if detected with #if _has_include

> All that's not strictly required for acceptance, in principle; neither
> is using Boost.Config instead of rolling your own. And yet.

Boost-lite macros can be swapped for Boost.Config ones if reviewers wish it.

I should mention that boost-lite derives its macros from the C++ 17
feature macros, which all recent editions of major compilers support
even in C++ 14 mode. In other words, it is not compiler version based,
except on old compilers, but it does rely on compiler vendors telling
the truth (they generally do).

> Regarding the ring buffer, I agree that it adds value. But it also adds
> complexity. There's an argument to be made for result/outcome classes
> that simply store std::error_code without all the bells and whistles,
> and provide an optional hook to which the user can attach the ring
> buffer if needed.

The tutorial covers the need in real world code to attach some sort of
payload to error codes. Outcome provides error_code_extended with a
reasonable set of the most common likely payloads.

If reviewers would prefer a vanilla error_code to be the default, that's
very easy to fix. I would add that if you do not use any of the payload,
error_code_extended is identical to an error_code, no overhead.

> Finally, you don't even need to macro-bind to std::error_code. Inspired
> by Outcome, I wrote a pull request for Boost.System which makes the
> Boost error_category, error_code and error_condition convertible to the
> standard ones, so you can just store std::error_code and be done with it.
>
> https://github.com/boostorg/system/pull/16

I'll leave it to reviewers to decide on whether defaulting to the C++ 14
STL std::error_code or to boost::error_code is the most appropriate.
It's very easy to change. And as I've mentioned before, if reviewers
really want a completely boostified edition of Outcome, that's no
problem, I can make that work.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
Niall Douglas wrote:
> > The vast majority of your user base may change if your library is
> > accepted. It almost certainly will.
>
> I would still expect a vast majority to not want a Boost dependency.

The vast majority get their Boost libraries through some form of a Boost
release. For them, the phrase "a Boost dependency" makes no sense at all.
You could legitimately talk about depending (or not depending, which is
preferable) on a specific Boost module, but not depending on Boost in
general has no meaning when you're part of Boost in general.

> People want C++ 14 libraries to use the C++ 14 STL, not Boost,

Not a problem at all here, but not what we're talking about. You've
eliminated a dependency on Boost, but substituted a dependency on something
called Boost Lite. For people who acquire your library as part of Boost,
this is not an asset, it's a liability. (For those who don't, it's vice
versa.)

> Including Outcome does not include <windows.h>, except on winclang

Yes, I happened to have my toolset set to Clang.

> I should mention that boost-lite derives its macros from the C++ 17
> feature macros, which all recent editions of major compilers support even
> in C++ 14 mode.

Does MSVC support SD-6 macros? I thought that it didn't.

> The tutorial covers the need in real world code to attach some sort of
> payload to error codes. Outcome provides error_code_extended with a
> reasonable set of the most common likely payloads.

Yes, the need to attach more information to error codes is genuine. For
exceptions Boost.Exception lets us do that non-intrusively, but for error
codes we do not have a similar framework.

Speaking of which, can you please give me a few examples of what goes into
the two codes (code1 and code2)?

> I would add that if you do not use any of the payload, error_code_extended
> is identical to an error_code, no overhead.

Apart from the additional size_t. But it occurs to me that you can hide that
on x64 if (a) you make it 32 bit - should be enough for a ring buffer - and
(b) you do not derive from std::error_code but instead store the members
directly in the correct order.

    int32_t cookie_;
    int value_;
    std::error_category const * cat_;

> I'll leave it to reviewers to decide on whether defaulting to the C++ 14
> STL std::error_code or to boost::error_code is the most appropriate.

I'm not sure you understand me here... I'm saying that there's no need to
default to boost::error_code or even keep the stl11:: way of choosing
between the two.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
On 21/05/2017 14:39, Peter Dimov via Boost wrote:
> Niall Douglas wrote:
>> > The vast majority of your user base may change if your library is >
>> accepted. It almost certainly will.
>>
>> I would still expect a vast majority to not want a Boost dependency.
>
> The vast majority get their Boost libraries through some form of a Boost
> release.

The vast majority do something like:

apt-get install libboost-filesystem-dev

So they ask for the library they need, and get lots of other stuff too
(filesystem is actually pretty good, only four or five dependent boost
libraries, others basically drag in libboost-all-dev)

> For them, the phrase "a Boost dependency" makes no sense at
> all. You could legitimately talk about depending (or not depending,
> which is preferable) on a specific Boost module, but not depending on
> Boost in general has no meaning when you're part of Boost in general.

All the evidence to date suggests that people far prefer Boost libraries
without the monolithic Boost dependency, and especially without a
Boost.Build dependency.

Standalone ASIO is much more popular than Boost.ASIO

Standalone Hana I am told is much more popular than Boost.Hana, but
maybe Louis will confirm or deny.

I expect the same to be the case with standalone Outcome. An
overwhelming majority of developers outside boost-dev want Boost quality
libraries without the Boost dependency. This topic comes up **very**
frequently on Reddit and Stackoverflow. People have tried to explain
this here on boost-dev, but it has not been well received. I don't want
to rehash those arguments during this review. I've said all I intend to
on that topic.

I will reiterate that if reviewers want a boost-flavoured Outcome which
doesn't default to the C++ 14 STL, that's no problem to achieve.

>> People want C++ 14 libraries to use the C++ 14 STL, not Boost,
>
> Not a problem at all here, but not what we're talking about. You've
> eliminated a dependency on Boost, but substituted a dependency on
> something called Boost Lite. For people who acquire your library as part
> of Boost, this is not an asset, it's a liability. (For those who don't,
> it's vice versa.)

It is not a dependency if it comes bundled internally. Which it does. No
external downloads nor installs needed unless you are using the git repo
(and even then, fetchRecurseSubmodules is set to true, so a simple git
submodule update should work if your git is new enough).

>> I should mention that boost-lite derives its macros from the C++ 17
>> feature macros, which all recent editions of major compilers support
>> even in C++ 14 mode.
>
> Does MSVC support SD-6 macros? I thought that it didn't.

I believe they appeared in an update of VS2015, and are present in
VS2017. __has_include also appeared and mostly works, though it is buggy.

>> The tutorial covers the need in real world code to attach some sort of
>> payload to error codes. Outcome provides error_code_extended with a
>> reasonable set of the most common likely payloads.
>
> Yes, the need to attach more information to error codes is genuine. For
> exceptions Boost.Exception lets us do that non-intrusively, but for
> error codes we do not have a similar framework.

Boost.Exception allocates memory to do that. Allocation of memory is not
possible anywhere in Outcome, it ruins the point of using it for low
latency C++ which is a big user base.

> Speaking of which, can you please give me a few examples of what goes
> into the two codes (code1 and code2)?

Totally up to the end user.

You could store a void * across both 32 bit codes.

You could store a thread id in one and the bottom 32 bits of this in the
other.

Lots of options. I chose 64 bits as it's the minimum which is versatile.

In my own code, I define a local make_errored_result<>() function which
wraps the Outcome one, but adds in custom code1 and code2 where appropriate.

>> I would add that if you do not use any of the payload,
>> error_code_extended is identical to an error_code, no overhead.
>
> Apart from the additional size_t.

I benchmarked the effects of that additional 8 bytes. No statistically
measurable difference.

> But it occurs to me that you can hide
> that on x64 if (a) you make it 32 bit - should be enough for a ring
> buffer - and (b) you do not derive from std::error_code but instead
> store the members directly in the correct order.
>
>    int32_t cookie_;
>    int value_;
>    std::error_category const * cat_;

The ability to implicit type slice an error_code_extended to an
error_code may well be felt to be an issue by reviewers. If explicit
conversion were felt desirable despite creating boilerplate, then
definitely yes you'd optimise storage. But as I mentioned, I found no
statistical difference in performance with the additional 8 bytes. After
all, one is not creating large arrays of error_code_extended.

>> I'll leave it to reviewers to decide on whether defaulting to the C++
>> 14 STL std::error_code or to boost::error_code is the most appropriate.
>
> I'm not sure you understand me here... I'm saying that there's no need
> to default to boost::error_code or even keep the stl11:: way of choosing
> between the two.

Retaining standalone usability of Outcome is a high priority for me. A
lot of folk from SG14 are interested in using Outcome, and I intend to
submit Outcome into SG14's collection of low latency suitable libraries.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
Niall Douglas wrote:

> The vast majority do something like:
>
> apt-get install libboost-filesystem-dev

... which typically installs all Boost headers. I don't think that
maintainers split those, it's a lot of work and Boost releases do not
contain the information that's necessary to do it properly.

> > Speaking of which, can you please give me a few examples of what goes
> > into the two codes (code1 and code2)?
>
> Totally up to the end user.

I know that it's totally up to the end user. I'm asking for a few real-world
examples of use. What do you use them for, what do your users use them for?

> >> I'll leave it to reviewers to decide on whether defaulting to the C++
> >> 14 STL std::error_code or to boost::error_code is the most appropriate.
> >
> > I'm not sure you understand me here... I'm saying that there's no need
> > to default to boost::error_code or even keep the stl11:: way of choosing
> > between the two.
>
> Retaining standalone usability of Outcome is a high priority for me. A lot
> of folk from SG14 are interested in using Outcome, and I intend to submit
> Outcome into SG14's collection of low latency suitable libraries.

I'm now sure that you don't understand, because your answer makes no sense.
I'm telling you TO NOT USE BOOST::ERROR_CODE, and you tell me that you'd
rather retain standalone usability. Hello?


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 05/21/2017 04:35 PM, Niall Douglas via Boost wrote:

> Standalone ASIO is much more popular than Boost.ASIO

What do you base this statement on?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
>> Standalone ASIO is much more popular than Boost.ASIO
>
> What do you base this statement on?

Back when I did the research for my C++ Now talk on the future of Boost,
I did a search of open source projects #including "asio/asio" as against
"boost/asio". The "asio/asio" ones outnumbered "boost/asio" by approx
50% if I remember rightly.

I am subscribed to asio questions on stackoverflow, and there is a
noticeable pattern that people with beginner level questions use
boost.asio, whereas the tricky questions they are using standalone asio.
That suggests the serious users of ASIO use the standalone edition.

Finally, a quick google search of "boost.asio vs standalone asio"
reveals most of the top results recommend using standalone asio if you
have C++ 11 or better. The most common reason given is "because it is
truly header only and it doesn't drag in Boost".

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sun, May 21, 2017 at 7:35 AM, Niall Douglas via Boost <
[hidden email]> wrote:

> Standalone ASIO is much more popular than Boost.ASIO
>

What do you mean by that? You can't possibly mean that standalone
Boost.ASIO is more distributed by Boost -- Boost releases are everywhere!


> > Yes, the need to attach more information to error codes is genuine. For
> > exceptions Boost.Exception lets us do that non-intrusively, but for
> > error codes we do not have a similar framework.
>
> Boost.Exception allocates memory to do that. Allocation of memory is not
> possible anywhere in Outcome, it ruins the point of using it for low
> latency C++ which is a big user base.
>

Control may have exited low latency contexts. High level contexts may have
information relevant to an error detected and reported by low level code.
There is no harm in providing the _ability_ to carry it.

Secondly, the problem of memory allocation can be dealt with using
alocators and shared_ptr.

Generally, if a low level context has data that might be needed to handle
the error, there should be a mechanism to report it, doubly so because it
is tricky. By not dealing with this problem you're pushing that
responsibility to the users who may need it.

Retaining standalone usability of Outcome is a high priority for me. A
> lot of folk from SG14 are interested in using Outcome, and I intend to
> submit Outcome into SG14's collection of low latency suitable libraries.
>

Could it be that making it part of Boost is low priority then? Or at least
lower? :)

The way I see it, if you want to be part of Boost, you should be a "good"
member of Boost, and this does mean to *by default* include config, assert
with BOOST_ASSERT, throw using BOOST_THROW_EXCEPTION, and a few other
things. You can then support others users, for example let them #define
OUTCOME_STANDALONE and you #ifdef out all Boost dependencies.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
>> Totally up to the end user.
>
> I know that it's totally up to the end user. I'm asking for a few
> real-world examples of use. What do you use them for, what do your users
> use them for?

Oh, ok.

Here's an example from
https://github.com/ned14/boost.kerneltest/blob/5bf4b78569366198af745ec6b7319e0ed4d91f6e/include/boost/kerneltest/v1.0/hooks/filesystem_workspace.hpp#L440:

            // If this is empty, workspaces are identical
            result<stl1z::filesystem::path> workspaces_not_identical =
compare_directories<false, false>(current_test_kernel.working_directory,
model_workspace);
            // Propagate any error
            if(workspaces_not_identical.has_error())
              testret =
error_code_extended(make_error_code(kerneltest_errc::filesystem_comparison_internal_failure),
workspaces_not_identical.get_error().message().c_str(),
workspaces_not_identical.get_error().value());
            // Set error with extended message of the path which differs
            else if(workspaces_not_identical.has_value())
              testret =
error_code_extended(make_error_code(kerneltest_errc::filesystem_comparison_failed),
workspaces_not_identical.get().string().c_str());

So compare_directories() walks two directory structures using the
Filesystem TS and compares them for equivalence using fuzzy criteria.
Here we use the empty state to indicate "directory trees are identical",
an error state to indicate an error occurred, and a valued state to give
the path of the first item which differed.

(I know this looks like an inverted logic from traditional outcome
usage, but this shows exactly the usefulness of the three-state outcome.
Here empty is "failure to find a difference", valued is "succeeded to
find a difference")

If there was an error, we return an error code of
kerneltest_errc::filesystem_comparison_internal_failure with a payload
of the string message from the source error and its original error code
in the first 32 bit code1 integer. That is used later on to print the
exact error code returned by the system as we know it will always be
system_category.

If the directory structures differed, we return an error code of
kerneltest_errc::filesystem_comparison_failed with a payload of the
string of the path which did not match.


Is this sufficient, or would you prefer a different example?

>> >> I'll leave it to reviewers to decide on whether defaulting to the
>> C++ >> 14 STL std::error_code or to boost::error_code is the most
>> appropriate.
>> >
>> > I'm not sure you understand me here... I'm saying that there's no
>> need > to default to boost::error_code or even keep the stl11:: way of
>> choosing > between the two.
>>
>> Retaining standalone usability of Outcome is a high priority for me. A
>> lot of folk from SG14 are interested in using Outcome, and I intend to
>> submit Outcome into SG14's collection of low latency suitable libraries.
>
> I'm now sure that you don't understand, because your answer makes no
> sense. I'm telling you TO NOT USE BOOST::ERROR_CODE, and you tell me
> that you'd rather retain standalone usability. Hello?

Unless I have misunderstood your patch, you bring in error_condition
comparisons from <system_error> allowing one to compare error codes to
error conditions across both Boost and STL error categories.

This is fine, and indeed valuable. But it isn't relevant to Outcome
particularly because we cannot say what the end user is doing with their
error_code, and certainly not if whatever they are doing has any
relation to error_condition. For example, as mentioned earlier in the
thread, Chris was using a custom http_error category for the HTTP status
codes. That has no useful mapping onto error_condition except for the
identity map, and most code will therefore just go ahead and use the
error code directly and save on the boilerplate.

One could create one's own error_code implementation which uses the STL
or Boost error categories, and provide mapping into error_condition.
This would let you embed whatever payload you like into Outcome's
error_code. Indeed, if reviewers dislike error_code_extended storing the
payload into global static memory like it does, the next least worst
solution is probably one's own custom error_code implementation with
user definable payload.

But this is not a cost free design choice, you lose compatibility with
all code using std::error_code. The current design lets you do stuff
like static_cast from a passed in error_code& to an error_code_extended&
if you know the original is definitely an extended error code. I figured
that much more likely a use case in say something like ASIO which is
hard wired to use const error_code&. But maybe it's a price worth
paying. Let's see what reviews recommend.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> The way I see it, if you want to be part of Boost, you should be a "good"
> member of Boost, and this does mean to *by default* include config, assert
> with BOOST_ASSERT, throw using BOOST_THROW_EXCEPTION, and a few other
> things. You can then support others users, for example let them #define
> OUTCOME_STANDALONE and you #ifdef out all Boost dependencies.

Outcome is a good member of Boost. It ticks every box on the list of
requirements at http://www.boost.org/development/requirements.html
except for Boost.Build support.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
On Sun, May 21, 2017 at 2:35 PM, Niall Douglas via Boost
<[hidden email]> wrote:
> Outcome...ticks every box...at
> http://www.boost.org/development/requirements.html

Including "Aim first for clarity" ?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sun, May 21, 2017 at 2:35 PM, Niall Douglas via Boost <
[hidden email]> wrote:

> > The way I see it, if you want to be part of Boost, you should be a "good"
> > member of Boost, and this does mean to *by default* include config,
> assert
> > with BOOST_ASSERT, throw using BOOST_THROW_EXCEPTION, and a few other
> > things. You can then support others users, for example let them #define
> > OUTCOME_STANDALONE and you #ifdef out all Boost dependencies.
>
> Outcome is a good member of Boost. It ticks every box on the list of
> requirements at http://www.boost.org/development/requirements.html
> except for Boost.Build support.
>

I did not mean to suggest that this is a requirement, I said "should" not
"must". For example, if you don't use BOOST_THROW_EXCEPTION to throw, users
won't have the file, line and function name of the throw when calling
current_exception_diagnostic_information; and if you don't at least use
boost::throw_exception, you create problems for users who use Boost under
BOOST_NO_EXCEPTIONS, which seems would include users of Outcome.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Niall Douglas wrote:
...

> If there was an error, we return an error code of
> kerneltest_errc::filesystem_comparison_internal_failure with a payload of
> the string message from the source error and its original error code in
> the first 32 bit code1 integer. That is used later on to print the exact
> error code returned by the system as we know it will always be
> system_category.
>
> If the directory structures differed, we return an error code of
> kerneltest_errc::filesystem_comparison_failed with a payload of the string
> of the path which did not match.
>
> Is this sufficient, or would you prefer a different example?

Thanks, that's very helpful.

The use case here is similar to std::throw_with_nested, you have an
error_code that you are overriding with another. You could extend your ring
buffer facility to support this natively. For that, you need to store in the
buffer entry the error code (a duplicate of error_code_extended's members)
_and_ the unique_id of the "parent" error_info_extended. This would allow
you to later retrieve the whole chain of ring buffer entries (subject to
availability.) In your example, you'd do

    testret = error_code_extended(
kerneltest_errc::filesystem_comparison_internal_failure,
workspaces_not_identical.error() );

Since workspaces_not_identical.error() is already in the ring buffer, you
only need a 'pointer' to it in testret. There's also no need to pass its
message() in testret's message, you could use that for other purposes.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Niall Douglas wrote:

> Unless I have misunderstood your patch, you bring in error_condition
> comparisons from <system_error> allowing one to compare error codes to
> error conditions across both Boost and STL error categories.
>
> This is fine, and indeed valuable. But it isn't relevant to Outcome
> particularly because we cannot say what the end user is doing with their
> error_code, and certainly not if whatever they are doing has any relation
> to error_condition.

What the patch does is make boost::system::error_code and
boost::system::error_condition convertible to std::error_code and
std::error_condition.

The idea is that a function that returns std::error_code can use a function
that returns boost::system::error_code in its implementation and can then
return it directly.

In cases where the original boost::error_code can be compared to
boost::errc::foo, the converted std::error_code can be compared to the
equivalent std::errc::foo. In addition, if the original boost::error_code
can be compared to a custom boost::error_condition, the converted one can be
compared to the converted std::error_condition.

Long story short, the relevance to Outcome is that you can always store
std::error_code in result/outcome, even if the user passes you a
boost::error_code (because it will convert). There is no need to choose at
compile time which of the two to store, because you can take both. That is,
the function

    result<T> make_error_result( std::error_code const & ec );

will now be able to take Boost error codes as well.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
123
Loading...