V V tor., 23. okt. 2018 ob 10:44 je oseba Niall Douglas via Boost < boost@lists.boost.org> napisala:
I agree with RR, though, these things should not be part of C++, I don't even think the Network TS should be in the standard, it's highly specialized stuff, with heaps of pitfalls [most user posted problems on this list pertain to ASIO [and Beast (no criticism intended, it's just complicated stuff)].
For the past 8 years I'm using ASIO (and now Beast on top of it) to crate GUIs as I already know web development and certainly don't feel like bothering with either platform specific GUI stuff or heavy weight frameworks such as Qt, WxWidgets,... Especially because web has HTML5 with all the JavaScript libraries for manipulating graphics already in place. So from my point of view Networking TS covers a big chunk of my inter process communication and GUI implementation (in both cases localhost and remote) letting me ignore Apache/NginX, PHP, C# with its ASP.NET framework... You might argue that C++ is not the best tool for web dev (and I would disagree because I really hate the devops and dependency bloat that the alternatives bring to the table) but if you ignore the "which language to use" part you can see that web and GUI world is not a small portion of programming tasks and Networking TS covers it quite well for me as the basic layer. For me being a base layer for two very different things (networking and GUI) is something that most definitely belongs into the standard - especially since C++ standard is heavily lacking in those two departments.
I think there is widespread agreement that if we had a decent and universal package management solution, most of the standard library proposals before the committee would no longer be necessary.
Universal minus at least one... Since I had to fight the NuGet packaging manager in C# today (and have fought the Java maven dependency hell quite often in the past - different libraries requiring different versions of the same library that don't play nice with one another) I somehow still believe that package management solutions are still not developed enough to be really useful on the language level (rpm and deb repositories not included [meaning that they are useful] as those start to eat away your nerves only if you are using an old/under-packaged Linux distribution or really need a custom build of a latest-latest library version) - so I'm for OS level package management (other people invest time to make the libraries play nicely together by using the same versions of one library on which other depend all the way) and don't see a universal C++ package management solution as being the thing that solves allot of library problems. Interestingly, P1031 Low level file i/o and the Networking TS are not
examples of those. Both require changes to the core language to work well. So I think for those two at least, they'd be before the committee no matter what.
+1 Now regarding the future and present of Boost I'm not a contributor/maintainer but am a long time user and before C++11 Boost libraries helped me allot. Unfortunately after C++11 release Boost started to annoy me as my compilers supported more and more of the standard implementations while Boost libraries kept their dependencies on boost versions of those same library parts. This becomes an annoyance and for me puts Boost not side by side with C++ STD library - instead it puts Boost more towards the Qt basket where you get the feeling that they want to be the be all end all framework that tries not to care about STD library as much as humanly possible (I could be wrong regarding both library bundles/frameworks but that's the feeling I got). As an outsider that probably even doesn't have enough C++ experience to contribute to Boost I see usefulness of Boost libraries such as Asio, Beast, DLL, Spirit/X3 that are not (yet) part of the standard but solve my problems - but on the other hand I dislike that DLL requires boost::filesystem (had some additional issues building Boost because of that dependency and also had to convert to std::filesystem to boost::filesystem in the code) and even submitted a patch for Beast so that I don't need to bother with boost::string_veiw and may instead use std::string_view. So from one perspective I like Boost as a location where I know I'll find quality libraries that will solve my problems but from the other that's the most that I see in current Boost as I don't have a problem using fmt [1] https://github.com/fmtlib/fmt library that is not in Boost (but I'm glad that it's trying to get standardized - at least in part). So to sum up: For me as a Boost library user Boost is a library hub that no longer works with C++ STD library but instead tries to compete against it as a Boost-STD library - so just another competitive framework. From my point of view Boost would become once again a C++ STD addition if it would contain libraries that are missing from the (latest?) standard and would use C++ STD parts wherever possible - C++ STD for long term stability, Boost for innovation and complementing the standard instead of trying to support N previous standards (or by being packaged differently for each C++ standard - only libraries that are missing from that standard and using boost substitutes only if they are missing in that standard version). I know that that is an awful lot of work but my guess would be that these are one of the rare options for Boost to continue to be C++ STD complementary bunch of libraries that push the standard forward instead of being just another "I work alone" blob of libraries that are splitting C++ codebases and being better-quality-C++-only-github-2 (nothing wrong with that but a different direction to pre C++11 Boost). On the other hand the only way I'd see Boost as a better place for currently proposed C++ libraries for standardization would be if C++ standard would say something like "C++ compiler is compliant to standard X only if Boost libraries X, Y, Z... are shipped with it in a working state" - and until then I prefer libraries migrating slowly from Boost into the standard. Just my two (probably useless) cents. Regards, Domen https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon Virus-free. www.avast.com https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>