- Boost - lists.boost.org

Re: [boost] [Boost-users] Networking TS + Beast, NEW Tutorials, Read this to learn std::net !!!
by Vinnie Falco 15 Mar '19

15 Mar '19

On Fri, Mar 15, 2019 at 7:38 AM Stian Zeljko Vrba <vrba(a)quine.no> 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.

1 0

Re: [boost] [Boost-users] Networking TS + Beast, NEW Tutorials, Read this to learn std::net !!!
by Vinnie Falco 15 Mar '19

15 Mar '19

On Fri, Mar 15, 2019 at 7:19 AM Stian Zeljko Vrba <vrba(a)quine.no> wrote: > > I believe it is wrong to blame Asio for this. > > I disagree. Recently, I've been coding parallel, including networked & > asynchronous, programs in C# and Java, and the experience has been a JOY. You > get threads, executors, synchronization primitives, tasks, cancellation, > monadic futures and concurrent (blocking and non-blocking) data structures > out of the box with the platform, plus a myriad of extensions as libraries. > As for executors, you don't need to be bothered with them unless you really > want to for some reason. > If you were to compare POSIX or BSD sockets to C# and Java, you would say exactly the same things. Asio (like Beast) is a low-level, portable abstraction of I/O. You can BUILD "threads", "executors", "synchronization primitives", "tasks", "cancellation", "monadic futures", and "concurrent data structures" with it. Does this mean OS-level sockets are the wrong abstraction? Of course not. The reason C# seems "ahead" of C++ is two-fold: 1. WG21 goofed up by delaying networking 2. C# is not developed through the International Standards Process These mistakes are being fixed though, and you will see library support in C++ catch up by leaps and bounds. And when we finally get these things (built on top of Asio/Networking TS, which has proven over and over to be the correct low-level abstraction) it will be better than C#, Java, or Rust. Compare the documentation for Vertx (vertx.io) or netty (both Java toolkits > for writing asynchronous reactive programs) with that of asio. > Yes I agree, there is a lack of documentation and especially tutorials for beginners (which I am trying to fix). This has nothing to do with whether Asio is the right portable, low-level abstraction (it is) but the lack of guidance from the author could lead you to believe incorrect things about the lib. Once I attempted to write an asio service, tried to understand the simple > example from the documentation, and I gave up. I used a thread, blocking > call and CancelSynchronousIO (and I consider myself fortunate to develop > for Windows only that has it). > The documentation on services is particularly scant. There is no explanation of what they are for, how to use them, best practices, or even "Frequently Asked Questions." I was able to figure it out though, but I am able to focus all of my time on it. > Asio _is_ a relatively nice wrapper around socket and serial port APIs, > but that's about it > Yes now you're getting close to an accurate description. More correct would be to say that Asio provides robust abstractions of buffers, dynamic buffers, synchronous I/O, and asynchronous I/O. Networking is a subset of that (but not the only part, see signals and serial ports, and soon file I/O). > IMO. On the other hand, I could have written the same wrappers around > native APIs in two days and not haul along what I consider the baggage of > technical debt that is asio in the codebase. > There is no API technical debt. That is to say, that the interfaces are modern and up-to-date. You could argue that particular implementations such as Boost.Asio have extra code to provide C++03 compatibility, but this has nothing to do with the soundness of the design. As these interfaces are part of a TS, there will be implementations in gcc and clang appearing shortly (if not already so). These will be written from scratch so there will be no support for older C++. > Conclusion, if any: many people just want/need thread per client and > synchronous IO for simplicity, but until asio/networking TS provide for > timeouts and cancellation of synchronous requests, it's a wrong tool for > those people, me included. > If you define struct sync_socket { net::io_context ioc_; net::ip::tcp::socket_; net::steady_timer timer_; ... template<class Buffers> std::size_t write_some (Buffers const& b); }; You can easily implement timeouts in `write_some` thusly: template<class Buffers> std::size_t sync_socket:: write_some (Buffers const& b, error_code& ec) { std::size_t n; timer_.expires_after(seconds(30)); timer_.async_wait( [&](error_code ec) { socket_.cancel(ec): }); socket_.async_write_some(b, [&](error_code ec_, std::size_t n_) { ec = ec_; n = n_; }); ioc_.run(); return n; } Now, you can use `sync_socket` with all the usual sync write operations like `net::write`, and get timeouts. Thanks

1 0

Re: [boost] [Boost-users] Networking TS + Beast, NEW Tutorials, Read this to learn std::net !!!
by Vinnie Falco 15 Mar '19

15 Mar '19

On Fri, Mar 15, 2019 at 2:45 AM Cristian Morales Vega <cristian(a)samknows.com> wrote: > I have not used the synchronous API at all. But section 3.1 of P1269R0 > seems to make a good point about the lack of timeouts in synchronous > calls, doesn't it? > beast::basic_stream makes using timeouts in the async API way simpler, > but is the sync API really basically unusable because of the lack of > timeouts thing? Synchronous APIs are perfectly fine. Asio defines SyncReadStream and SyncWriteStream named requirements, allowing for generic algorithms to be implemented. Not everything is a socket (for example, a serial port). A synchronous stream represents the reliable, in-order delivery of bytes using functions that block, nothing more and nothing less. For example, serial file I/O can be represented using a synchronous stream. If the synchronous stream requirements mandated timeouts, it would eliminate a broad set of implementations (including sockets on some platforms).

1 0

Status of Disjoint Sets ?
by Brian Kuhl 15 Mar '19

15 Mar '19

Disjoint Sets is in the last few releases, has it's own test suite and github archive, but isn't mentioned on the documentation page? An oversight, or intentional? https://www.boost.org/doc/libs/1_69_0/ I see a defect that says it should move into Graph, is that part of the puzzle? https://github.com/boostorg/disjoint_sets/issues Brian

2 1

Networking TS + Beast, NEW Tutorials, Read this to learn std::net !!!
by Mike 15 Mar '19

15 Mar '19

> All in all nice intro, unfortunately it requires users to understand > templates quite well, but honestly not sure if it is avoidable, with a > gazillion customization points in ASIO. Anyone aware of a wrapper library around ASIO that doesn't offer all those customization points and maybe not the full functionality/ efficiency but is easier to use? Am 15.03.19, 01:09, Ivan Matek via Boost <boost(a)lists.boost.org> schrieb: Here are comments from somebody who "knows C++" but does not know a lot about NW and has read only the 1st <[1]https://www.boost.org/doc/libs/master/libs/beast/doc/html/beast/ using_io/asio_refresher.html> page. // get iterators representing the range of characters in the buffer auto begin = range::begin(buffer.data()); auto end = range::end(buffer.data()); Quite a weird pattern, where buffer does not have member begin, end. Maybe a sentence or two describing the rationale and complexity would be nice. I know it is O(1), but it is weird that begin/end are called on pointer. std::size_t read_lineI am tired, but is this function O(n^2)? cb += bytes_transferred; // adjust the pointer and sizeI would maybe switch to write instead of write_some to keep the code shorter, and mention write_some as another option in text. [](error_code ec, std::size_t bytes_transferred) For learning purposes I would capture something in lambda by value and note that reference capture would be buggy. using type = std::allocator<void>; Personal preference: not a fan of typedefs for relatively short types used once. All in all nice intro, unfortunately it requires users to understand templates quite well, but honestly not sure if it is avoidable, with a gazillion customization points in ASIO. _______________________________________________ Unsubscribe & other changes: [2]http://lists.boost.org/mailman/listinfo.cgi/boost References 1. https://www.boost.org/doc/libs/master/libs/beast/doc/html/beast/using_io/as… 2. http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Coordinating Boost Releases with compiler releases
by Marshall Clow 14 Mar '19

14 Mar '19

In the thread "MSVC 2019 and 1.70 beta", there has been a discussion about what to do about support for MSVC 2019, which is due to be released right about the same time that Boost 1.70. One person suggested that we delay the boost release until after the MSVC release (I think the suggestion was "May"). This general question has been discussed before (several times), since tools get released fairly often - and so does Boost. In general, I am not in favor of delaying boost releases in order to add support for 'about to be released' development tools. There are two main reasons for this: * There's always another compiler / tool about to be released. Clang 8 is imminent - currently at RC5. GCC 9.1 is scheduled to be released in early May. * Boost releases happen every four months. August is not really that far off. People who want support for tool XXXX can use "the trunk", getting it either from git or from bintray. [ Everyone knows about the tarballs at bintray, right? https://dl.bintray.com/boostorg/master/ ] Also, if we were to delay the boost release until May, then what would happen to the August release? The release process for 1.71.0 is scheduled to start at the end of June. -- Marshall

5 7

[filesystems]
by Florian Lindner 14 Mar '19

14 Mar '19

Hello, I have this innocent piece of code: namespace fs = boost::filesystem; auto path = getFilename(); // returns a string fs::create_directories(fs::path(path).parent_path()); std::ofstream ofs(path + "~"); ofs << info; ofs.close(); fs::rename(path + "~", path); which causes the exception: boost::filesystem::rename: No such file or directory: "../9f/061b4f7a5e529c964659226eedd4e5~", "../9f/061b4f7a5e529c964659226eedd4e5" However, I have no idea how that could happen. I use the rename, so that a reading process never sees an empty file, but only no file or filed with info. Is there any race involved between ofs.close() and fs:rename()? The code was executed on a distributed network filesystem (lustre). Any ideas anyone? Thanks, Florian

5 9

Re: [boost] [Boost-users] Networking TS + Beast, NEW Tutorials, Read this to learn std::net !!!
by Vinnie Falco 14 Mar '19

14 Mar '19

On Thu, Mar 14, 2019 at 10:50 AM james <dirtydroog(a)gmail.com> wrote: > This is excellent news. Timeouts are ASIO's biggest downfall. I'll definitely check it out. > If it's low level, and performant enough, then it paves the way for ASIO-ed connectors for things like Redis and ZeroMQ. Thanks! And we are very happy to answer questions, feel free to open an issue or come to the #beast Slack channel. Regards

1 0

Cannot serialize pointer through base without void_cast_register and register_type.
by Nicolas Guillot 14 Mar '19

14 Mar '19

Hello. *** CONTEXT *** I use your serialization library since several years on linux (gcc). Now, I'm moving to windows (_MSC_VER == 1600) (boost 1.55, but same issues on boost 1.69). For my example, I use a class A in a DLL, another class B inheriting from A in its DLL and an exe, linked to those DLLs, which serializes a B object, through its A base. _______ | A | ------- /_\ | | _______ | B | ------- I make a class serializable like that (I summurize on purpose (no #include, ...)). For A it's the same thing, but it has no base class. ----> B.h ---------------------------------------- #ifdef B_EXPORTS #define B_DLL __declspec(dllexport) #else #define B_DLL __declspec(dllimport) #endif class B_DLL B: public A { public: B(); virtual ~B(); private: friend class boost::serialization::access; template <class Archive> void serialize(Archive & ar, const unsigned int version); int i; }; BOOST_CLASS_EXPORT_KEY(B) ----> B.cpp ---------------------------------------- B::B() : i(123) {} B::~B() {} template <class Archive> void B::serialize(Archive & ar, const unsigned int) { ar & SERIALIZE_BASE(ClassA); ar & SERIALIZE(i); } #define FULL_SCOPED_SERIALIZABLE_CLASS B #include "Common/InstanciateSerializationTemplate.h" ----> InstanciateSerializationTemplate.h ---------------------------------------- This file purpose is to instanciate the template B::serialize methods for each archive type, and to register the class. Here is its contents (once again, no namesapce nor include to make it easier to read): // explicit instantiate code for all archive types expected to be use: // MUST COME BEFORE BOOST_CLASS_EXPORT_IMPLEMENT // binary: template __declspec(dllexport) void FULL_SCOPED_SERIALIZABLE_CLASS::serialize<binary_iarchive>(binary_iarchive & ar, const unsigned int version); template __declspec(dllexport) void FULL_SCOPED_SERIALIZABLE_CLASS::serialize<binary_oarchive>(binary_oarchive & ar, const unsigned int version); // XML: template __declspec(dllexport) void FULL_SCOPED_SERIALIZABLE_CLASS::serialize<xml_iarchive>(xml_iarchive & ar, const unsigned int version); template __declspec(dllexport) void FULL_SCOPED_SERIALIZABLE_CLASS::serialize<xml_oarchive>(xml_oarchive & ar, const unsigned int version); // TXT: template __declspec(dllexport) void FULL_SCOPED_SERIALIZABLE_CLASS::serialize<text_iarchive>(text_iarchive & ar, const unsigned int version); template __declspec(dllexport) void FULL_SCOPED_SERIALIZABLE_CLASS::serialize<text_oarchive>(text_oarchive & ar, const unsigned int version); BOOST_CLASS_EXPORT_IMPLEMENT(FULL_SCOPED_SERIALIZABLE_CLASS) *** MY ISSUE *** All that stuff works in linux, gcc, but not in Windows. If I write in my exe this serialization code: std::ofstream ofs; ofs.open("D:\\TestSerial.xml"); boost::archive::xml_oarchive ar(ofs); shared_ptr<B> b = shared_ptr<B>(new B()); shared_ptr<A> a = b; try { ar << SERIALIZE(a); } catch (boost::archive::archive_exception& ex) { std::cout << "Serialization to stream error, what: " << ex.what() << std::endl; } catch (...) { std::cout << "Catch ... Serialization to stream error" << std::endl; } ofs.close(); With this code, I have an archive_exception: "unregistered class - derived class not registered or exported". I have to write the serialization like that: ar.register_type(static_cast<B*>(0)); boost::serialization::void_cast_register(static_cast<B*>(0), static_cast<A*>(0)); ar << SERIALIZE(a); *** QUESTION *** At least, my question: I cannot do like that: what I would like to achieve: when a new class is made serializable like above, I expect the class to be registered automatically (probabley with BOOST_CLASS_EXPORT_IMPLEMENT in InstanciateSerializationTemplate.h). It's too painfull to write the register_type and void_cast_register each time I want to serialize. What am I missing? Thank you very much for any help or recommandations. Nico

1 1

Re: [boost] MSVC 2019 and 1.70 beta
by Peter Dimov 14 Mar '19

14 Mar '19

> Tom Kent wrote: > > > Build support for VS 2019 RC (msvc-14.2) is on develop in boost build. > > Do we want to merge that to master for the release? > > I think we do. 1.70 and 2019 will release at about the same time. In fact looking at the calendar, 2019 will release (Apr 2) just before 1.70 is closed for release (Apr 3.)

3 3