- Boost-users - lists.preview.boost.org

Passing io_service to socket in implementation file after initialization in header file
by Álvaro Cebrián Juan 19 Jun '18

19 Jun '18

If I initialize an io_service object and a socket object in my header file, how do I pass io_service to the socket as a parameter in my implementation file? Take this header file as an example: // foo.h > > #include <boost/asio.hpp> > > class foo > { > public: > > foo(); // Constructor. > > private: > > boost::asio::io_service ios; > > boost::asio::ip::udp::socket sock; > }; > And the corresponding implementation file: // foo.cc > > #include "foo.h" > > foo::foo() > { > sock(ios); // <-- This throws a compiler error. > } > Why doing *sock(ios);* doesn't work? What is the proper way to do it? Thank you. Álvaro

6 10

operator<< for std::vector< boost::variant< type_a, type_b >>
by Maarten Verhage 18 Jun '18

18 Jun '18

Dear boost-savvy people, I fail to understand how I need to write a working ostream overload for a type I have. I've read the boost::variant documentation. As well as stackoverflow question: https://stackoverflow.com/questions/46343138/using-stdvectorboostvariant-wi… Still I fail to understand how to make it work for the type I have. In the code you can see parameter_t is an element in the employee_t. I need to keep this data structure this way. Attached is my single 30 line problem code. I do compile with gcc 5.1.0 with C++14 support. It doesn't compile. The important part of the compiler output might be: C:\dev\boost_1_67_0/boost/variant/detail/variant_io.hpp:64:14: error: no match for 'operator<<' (operand types are 'std::basic_ostream<char>' and 'const std::vector<boost::variant<int, double> >') out_ << operand; My overload is obviously wrong. I would be very happy if someone can show me how to make it work. Best regards, Maarten Verhage

3 8

Why do socket::receive() and socket::async_receive() have different return types?
by Álvaro Cebrián Juan 14 Jun '18

14 Jun '18

>From the documentation I can see that socket::receive() <https://www.boost.org/doc/libs/1_58_0/doc/html/boost_asio/reference/basic_d…> returns a variable of type "std::size_t", while the asynchronous version socket::async_receive() <https://www.boost.org/doc/libs/1_58_0/doc/html/boost_asio/reference/basic_d…> returns "void". This is also true for socket::send() <https://www.boost.org/doc/libs/1_58_0/doc/html/boost_asio/reference/basic_d…> and socket::async_send() <https://www.boost.org/doc/libs/1_58_0/doc/html/boost_asio/reference/basic_d…> . I was expecting that they would have the same return types, so there might be a good reason behind. I would be grateful if someone can shed some light on this. Thank you. Álvaro

5 4

[boost] [release] 1.68.0 deadline for new libraries approaching
by Marshall Clow 12 Jun '18

12 Jun '18

One week from tomorrow master will closed for new libraries. Upcoming dates: * 20-Jun: Boost 1.68.0 closed for new libraries and breaking changes * 27-Jun: Boost 1.68.0 closed for major code changes * 4-Jul: Boost 1.68.0 closed for beta * 11-Jul: Boost 1.68.0 beta 1 * 1-Aug: Boost 1.68.0 closed for release * 4-Aug: Boost 1.68.0 release -- The Boost Release Team

1 0

Serialization over UDP
by Álvaro Cebrián Juan 11 Jun '18

11 Jun '18

Hello everyone, I have no prior experience with Boost. I need to serialize an object and send it over UDP to a remote machine. I already have a completely functional serialization mechanism over TCP and I would like to convert it to UDP. The member function that I use to serialize the objects over TCP looks like this: /// Asynchronously write a data structure to the socket. > template <typename T, typename Handler> > void async_write(const T& t, Handler handler) > { > // Serialize the data first so we know how large it is. > std::ostringstream archive_stream; > boost::archive::text_oarchive archive(archive_stream); > archive << t; > outbound_data_ = archive_stream.str(); > > // Format the header. > std::ostringstream header_stream; > header_stream << std::setw(header_length) > << std::hex << outbound_data_.size(); > if (!header_stream || header_stream.str().size() != header_length) > { > // Something went wrong, inform the caller. > boost::system::error_code > error(boost::asio::error::invalid_argument); > socket_.get_io_service().post(boost::bind(handler, error)); > return; > } > outbound_header_ = header_stream.str(); > > // Write the serialized data to the socket. We use "gather-write" to > send > // both the header and the data in a single write operation. > std::vector<boost::asio::const_buffer> buffers; > buffers.push_back(boost::asio::buffer(outbound_header_)); > buffers.push_back(boost::asio::buffer(outbound_data_)); > boost::asio::async_write(socket_, buffers, handler); > } > As you can see in the code, it makes use of streams to write the serialized data asynchronously to the remote machine. This is fine for TCP, since this protocol is stream-oriented. However, as far as I know, this does not work for UDP because it is message-oriented and therefore it does not support streams. Thus, I would be very grateful if someone could shed some light on which tools does Boost provide that would make serialization feasible over UDP. Thank you. Best Regards, Álvaro

2 1

Bug when using boost::optional with boost::program_options?
by Jim Porter 06 Jun '18

06 Jun '18

Before I spend too long tracking this down (I'm only seeing it in an Appveyor Windows build, since I do most of my work on Linux), I wanted to see if anyone else has experienced this issue. I'm trying to use boost::program_options to parse a command line arg and store it into a boost::optional, however I get a surprising compilation error[1]. This appears to have been introduced sometime between Boost 1.60 and 1.62 (Appveyor doesn't have Boost 1.61). I see that there were some significant changes to boost::optional between those revisions, so maybe that's the cause? The following test case *might* reproduce the issue, but sadly, rextester only has Boost 1.60, so it works there[2]. If it fails for someone with Boost 1.62+, then great! (Well, not "great", but you know what I mean.) Interestingly, it's not until Boost 1.65[3] that boost::program_options claims to support storing values into boost::optional; it's worked for me since long before that, possibly because I `#include <boost/optional/optional_io.hpp>`. If this isn't enough for others to help confirm this issue, that's ok; I'll try to get a Windows dev environment set up to provide more details in the coming week. I just wanted to send this out before I forgot about it... If it matters, the Appveyor build I'm seeing this with uses Visual Studio 2015 Update 3. Thanks, - Jim [1] https://hastebin.com/awutivawew.txt [2] http://rextester.com/QGBH48883 [3] https://www.boost.org/users/history/version_1_65_0.html

4 9

Can't build Boost sgd libraries using VC
by Ed Bronkowski 05 Jun '18

05 Jun '18

2 1

boost::process::win32_launch(...) with unicode working directory - Urgent
by Chandrasekhar B 04 Jun '18

04 Jun '18

Dear Users, I have trouble using the following boost api. I am developing application for Non English OS. The working directory is non-english for this case. If I set the working directory to Japanese or any other non-english language, the process does not start. I have few files that need to be read from the working directory. however, if I launch the process from the cmd line (whose path is again some Unicode text) the process launches fine. boost::process:win32_launch(const Executable &exe, const Arguments &args, const Win32_Context &ctx) is there any way to support unicode path for working directory within boost? Regards Chandrasekhar

1 0

How to build shared boost with clang-win?
by JR Cary 03 Jun '18

03 Jun '18

Windows 7 VSS2017 (1911) LLVM-6.0.0-win64 ./bootstrap.bat (works) ./b2 -d+2 -q toolset=clang-win runtime-link=shared link=shared cxxflags='/std:c++14 /EHsc /MD' address-model=64 threading=multi variant=release -s NO_COMPRESSION=1 --layout=system --abbreviate-paths -j1 --without-python --without-mpi --without-log --without-math stage fails at clang-linux.link.dll bin.v2\libs\atomic\build\clng-lnx-win\rls\thrd-mlt\boost_atomic.dll "clang++" -o "bin.v2\libs\atomic\build\clng-lnx-win\rls\thrd-mlt\boost_atomic.dll" -Wl,-soname -Wl,boost_atomic.dll -shared -Wl,--start-group "bin.v2\libs\atomic\build\clng-lnx-win\rls\thrd-mlt\lockpool.obj" -Wl,-Bstatic -Wl,-Bdynamic -Wl,--end-group -m64 -pthread It looks like clang-win is trying to use clang++ to link? Should it no use clang-cl? Thanks....John Cary

1 0

Plans to add parameter parsing in Beast?
by David Demelier 30 May '18

30 May '18

Hello, I'm trying to use Beast, it works fine and looks promising. Unfortunately, it looks like (unless I'm wrong) that there is no facilities to parse URL parameters or POST data. Such as /foo&option1=1&option2=2 Or simply form data: option1=1&option2=2 Are there plans to add such things or is definitely a non-goal of Boost Beast? Regards, -- David

2 2