Remember, C++ is often used where no other high-level language has gone before.
I'm well aware of that. However, how is that an argument for also not providing user-friendly, "instant productivity" high-level wrappers? By not doing that, developers having simple needs with reasonable [1] defaults are doomed to chase the rabbit-hole of complex specifications and reinvent the wheel again and again. Countless hours of programmer productivity wasted.
[1] Yes, what is reasonable? Look towards C# or Java. The wheel has already been invented.
Also, when it's easier (at least to me) to grasp raw Win32/Linux APIs than to study asio concepts and how they fit together, then the whole purpose of the standard library is defeated. Because: given an option of A: use time to learn concepts valid in C++ world only; option B: use (less) time to learn and use general OS mechanisms and concepts.. I know which route I'm going to choose and which route gives more long-term and more reusable knowledge. And probably a faster way towards working code, which is what matters in the end.
-- Stian
________________________________
From: Damian Jarek
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
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@lists.boost.orgmailto:Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users