Boost logo

Boost Users :

Subject: Re: [Boost-users] Networking TS + Beast, NEW Tutorials, Read this to learn std::net !!!
From: Damian Jarek (damian.jarek93_at_[hidden])
Date: 2019-03-15 18:08:32

I think you largely underestimate how many (often conflicting) requirements
and user expectations a high-quality C++ library has to deal with. While
efficiency in the C# world is no doubt important, it's worth remembering
that a high-quality C++ library needs to be precisely specified and be very
specific with its requirements and guarantees. This is why there's so many
concepts required to grasp - ASIO has to introduce the necessary vocabulary
to be able to provide an exact specification. Few, if any, C# programmers
need to worry where a library gets their memory from or whether said
library has customization points that allow the user to plug any homegrown
async model they use in their project into the library (which is why ASIO
has `async_result` and allows you to customize memory allocations via
allocators where applicable). Additionally, judging by the API you mention,
few C# users have a need to do efficient scatter-gather using non-contigous
buffers. Remember, C++ is often used where no other high-level language has
gone before.

I could go on and put features from both ASIO and the C# async library
side-by-side, but I think you get the picture. C++ libraries aren't complex
because library developers like to masturbate while watching listings of
their code - the complexity is there for a purpose (of course, sometimes
it's not justifiable, mistakes happen). Library authors in higher-level
languages can often make a lot of arbitrary decisions in a library, likely,
because their users don't mind for the most part. In C++, a component that
makes arbitrary decisions without any way to change them or to customize,
most likely doesn't get used (anyone remember std::async() ?).

On Fri, Mar 15, 2019 at 4:50 PM Stian Zeljko Vrba via Boost-users <
boost-users_at_[hidden]> wrote:

> > I see now...your ideas on how to implement it in C++
> convince me more than anything that the documentation is the problem.
> The documentation definitely is a problem, but consider the following
> trade-offs:
> - It took me half an hour to write the function in C# based on simple
> platform-provided and easily discoverable abstractions (IntelliSense lists
> ReadAsync just by side with Read; from there on it's easy to discover the
> remaining bits and pieces, and there's not much more to understand for the
> simplest use cases like that one).
> - It'd probably take me 2-3 hours to implement the said thread/queue
> algorithm. It'd be boring, "obviously correct" code, built on simple
> concurrency primitives, understandable and maintainable by others. It'd
> also have simple failure modes.
> - It'd take me ?? hours to understand the myriad of underlying asio
> concepts and their interplay, ?? hours to implement it, ?? hours to test it
> suitably (or become convinced of correctness in another way) and it'd have
> more complex failure modes (as anything else asynchronous). Also it would
> probably be non-understandable "black magic" to others who haven't spent at
> least ?? hours understanding the same bits of asio as well.
> I have taken a look at your tutorial on writing composed operations --
> which is very well written -- but I already see that the time required to
> read and understand it is longer than the time I used to implement the
> pasted C# snippet. (Yes, it demonstrates a different use-case, but the
> point stands I believe.)
> I'm not disputing that asio is built on solid abstractions and concepts,
> what I'm trying to say is that "something" should exist that would allow me
> to write the same functionality in 30 minutes in C++ the only prior
> knowledge being "there exists primitive for asynchronously reading from a
> file" (the same prior knowledge in the case of C#).
> Whether that "something" is "documentation for dummies", a "book of
> recipes", high-level utility library, … ?, I do not know.
> I only know that I'm 2-3X more productive in Java/C# than in C++
> (collusion of different factors; another story), and the gap is increasing.
> Working code needs to be delivered, customers are waiting and there's only
> so much time one can dedicate to studying arcane details of solidly
> designed but on the first sight impenetrable libraries.
> -- Stian
> ------------------------------
> *From:* Vinnie Falco <vinnie.falco_at_[hidden]>
> *Sent:* Friday, March 15, 2019 3:46:07 PM
> *To:* Stian Zeljko Vrba
> *Cc:* boost_at_[hidden] List; boost-users_at_[hidden]
> *Subject:* Re: [Boost-users] Networking TS + Beast, NEW Tutorials, Read
> this to learn std::net !!!
> On Fri, Mar 15, 2019 at 7:38 AM Stian Zeljko Vrba <vrba_at_[hidden]> wrote:
> > I have an idea of how to accomplish the same in C++, and
> > it's not pleasant -- worker thread, promise/future, blocking
> > queue and CancelSynchronousIO. Cannot even use
> > std::async because CancelSynchronousIO needs a
> > target thread ID.
> Yes, yes! I see now...your ideas on how to implement it in C++
> convince me more than anything that the documentation is the problem.
> There's no need for any of that stuff, the code you provided could be
> implemented in C++ using asio without too much fuss, and there are
> actually several ways to do it all of which are succinct and will work
> wonderfully.
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]

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