Boost logo

Boost Users :

Subject: Re: [Boost-users] Networking TS + Beast, NEW Tutorials, Read this to learn std::net !!!
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2019-03-15 20:45:10

>> And that I find a very fair criticism of the Networking TS
> You're doing the same thing that the OP did, which is blaming
> Networking TS for not doing enough.

That would be a mischaracterisation. What I said is that there is an
ideal design which lots of people would like if infinite development
resources were available. The kind of resourcing which .NET had, for
example. But we don't and didn't have that, so we don't get the
stupid-simple API part. We stop short in the complex intermediate API,
with the layers all smooshed together and indistinct. And not separated

> Please show me on the diagram why the availability of N and/or B are
> obstacles to implement SS?

Beast is an extreme example of a design wholly dependent on that of an
external library. As ASIO changes, you'll have to spent a lot of time
keeping up using resources which you'd prefer to invest elsewhere. This
is a big reason why people don't choose Boost, and instead do poor man's
local clones of Boost facilities. It guarantees no coupling on
externally moving targets.

For the same reason, it takes a lot of resources to build stupid simple
high level APIs on top of shifting lower level APIs. I'm not sure it can
be done by people unless full time employed to do so. And that's been
historically very hard in C++, only a very few parts of the standard
library were developed by people employed to solely do that and nothing

So tldr, it's not an engineering problem, it's a resourcing problem,
including the enormous resourcing requirement to build a consensus at
WG21 and get it through plenary. Look at the vast resourcing Ranges or
Coroutines sucked down, for example. High level stupid simple APIs are
hideously expensive to standardise, even for a big multinational
corporation like Microsoft (which largely sponsored both).


Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at