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

boost::asio::async_read Error Operation canceled
by jupiter 07 Aug '17

07 Aug '17

Hi, I have a client program written by someone who is no longer available. The client program can send a message via async_write to server, but when the server responded back, the client boost::asio::async_read got an error of Operation cancelled. Searching from the Internet, it said the program was caused mostly by using this which should be fixed by using shared_from_this(). But in my client program it does not use this or shared_from_this, could someone explains if it uses some default format implies to this or shared_from_this in following example? (What (=) means, some kind of lambda function?) boost::asio::async_read(this->socket, boost::asio::buffer(this->messageHeader), [=](const boost::system::error_code &error, const uint32_t length) {this->readMessageHeader(error, length);}); Thank you. Kind regards.

1 0

Boost.Test change between 1.56 and 1.64
by Dominique Devienne 06 Aug '17

06 Aug '17

1.56 class BOOST_TEST_DECL test_tree_visitor { public: // test tree visitor interface virtual void visit( test_case const& ) {} virtual bool test_suite_start( test_suite const& ) { return true; } virtual void test_suite_finish( test_suite const& ) {} protected: BOOST_TEST_PROTECTED_VIRTUAL ~test_tree_visitor() {} }; 1.64 class BOOST_TEST_DECL test_tree_visitor { public: // test tree visitor interface virtual bool visit( test_unit const& ) { return true; } virtual void visit( test_case const& tc ) { visit( (test_unit const&)tc ); } virtual bool test_suite_start( test_suite const& ts ){ return visit( (test_unit const&)ts ); } virtual void test_suite_finish( test_suite const& ) {} protected: BOOST_TEST_PROTECTED_VIRTUAL ~test_tree_visitor() {} }; To list test suites and test cases of our test exes, I implemented a custom visitor in Boost 1.56 and simply did const auto& master_ts = but::framework::master_test_suite(); but::traverse_test_tree(master_ts, visitor); This is broken in 1.64, none of the old methods from the visitor are called, and thus no suites or cases are discovered. Two out of 3 of the old methods are forwards to the new visit() method, and obviously the implementation only calls the new visit(). The forwarding should be in the other direction for backward-compatibility. Looking for visit/visitor in http://www.boost.org/doc/libs/1_64_0/libs/test/doc/html/boost_test/change_l… yield nothing. Can someone please shed some light on this incompatible change? Thanks, --DD

2 2

Boost statechart
by Georg Gast 02 Aug '17

02 Aug '17

Hi, as the last changelog entry in statechart is from 1.46. Is it still maintained? Greetings Georg

1 0

[review][mp11] Review report
by Bjorn Reese 02 Aug '17

02 Aug '17

I. VERDICT Mp11 is accepted unconditionally into Boost. There were 14 accept votes and 1 conditional accept vote. See list at end of this report. II. DESIGN Reviewers evaluated the design as very good. Many agreed with the design principle of using template aliases on type lists, which means that Mp11 can be used on std, boost, and custom type lists. Integration with MPL was discussed. This resulted in a new header file <boost/mp11/mpl.hpp> that enables the conversion between mp_list (and std::tuple) and MPL sequences. A version of mp_eval_if that can apply a metafunction to type lists in both the true and false branch was requested. This is not possible due to C++ limitations (template parameter pack must be at the end.) Instead two alternatives were suggested: (1) use a nested mp_eval_if in the true branch, or (2) use mp_if<>::type with mp_defer in both branches. Extra metafunctions were added for working with map and sets: mp_is_set, mp_is_map, and mp_map_keys which returns a list of all keys. No review without a discussion about names. The mp_ prefix received most comments. The prefix is used to avoid collision between mp11 names and C++ keywords. The argument against the mp_ prefix was that MPL and other Boost libraries already have established trailing underscore as the naming convention. The argument in favor is that the mp_ prefix is better suited for later C++ standardization. Other names that deviate from MPL, such as apply versus fn, were also pointed out, and the names of tuple operations were also discussed. III. IMPLEMENTATION The reviewers who looked at the implementation were generally pleased with its quality and simplicity. A faster version of mp_find was proposed during review. On reviewer pointed out that const lists causes obscure compilation errors. IV. DOCUMENTATION The evaluation of the documentation was more mixed. Some found it good, while others found it too terse. A recurring comment was that the documentation is missing beginner-level explanations and examples. For instance, the tuple_cat example was mentioned as being too advanced for an introduction. More examples with higher-order metafunctions (e.g. mp_bind) was requested. The reference documentation does not state the pre-conditions of the metafunctions. For example, what happens when indices are out of bounds? The description of map (list of lists) lead to confusion. Mp11 map entries have one unique key-type, and zero or more value-types. The ability to have multiple value-types per key-type makes it possible to emulate multi-maps. Some where unsure whether C++11 or C++14 was required for the library. There were plenty of other useful comments that I will omit from the review report for the sake of brevity. V. USEFULNESS The library was generally deemed useful. It was discussed if C++11 (and later) makes it too easy to write our own metaprogramming utilities, and thus not needing a metaprogramming library. This was not directed at Mp11 in particular. Some of the arguments in favor of a metaprogramming library were better performance and portability. I would like to add another advantage of a metaprogramming library, namely that it gives us a common vocabulary. VI. CONCLUSION The library fulfills the quality and usefulness criteria without major outstanding issues. The library is therefore cleared to be included into Boost. My main recommendation as review manager is to make the documentation more beginner-friendly before the library is added to Boost. This is a recommendation, not a requirement. VII. PARTICIPANTS The following formal reviews were posted: * Barrett Adair : Accept * Brook Milligan : Accept * Edward Diener : Accept * Glen Fernandes : Accept * Jason Rice : Accept * Joaquin M López Muñoz : Conditional accept * John P Fletcher : Accept * Lee Clagett : Accept * Paul Fultz : Accept * Peter Koch Larsen : Accept * Robert Ramey : Accept * Roberto Hinz : Accept * Vijayan : Accept * Vinnie Falco : Accept * Zach Laine : Accept I would like to thank all participants for their efforts. I would also like to thank Peter Dimov for bringing such a high-quality library to Boost.

2 1

boost-users@lists.boost.org
by phillip mobley 02 Aug '17

02 Aug '17

Hello all, I am a new user to boost. I am currently using the serialization library to save my data structures to a file. However, I am currently running into a few issues. At first, I was getting a lot of undefined errors. After reading on multiple forums, I realized that I forgot to link the serialization library to the project. Once done, all of the errors went away. Except for one. I am getting this error: /usr/local/boost_1_64_0/boost/serialization/throw_exception.hpp:36: undefined reference to `boost::archive::archive_exception::archive_exception(boost::archive::archive_exception const&)' I have been spinng my head around this for a few days. Did I forget to add in another referene somewhere? My code is setup in the same manner as the simple tutorial found on the boost::serialization page. This error only pops up when I have the line: boost::archive::text_oarchive oa(ofs); When I have this line commented out, I do not get the above error. Again, I am wondering if I forgot to reference something in my program but I am not sure. Any help will be greatly appreciated. <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

1 0

Which socket read get first when both asio::async_read and asio::read are active?
by jupiter 02 Aug '17

02 Aug '17

Hi, I have a socket server program to activate in asio::async_read for receive any messages initiated from client. But when the server sends a message to the client, it uses sync write and flowing a sync read (asio::read) to immediately receive the response. The issue I can think of is who will get first read when both asio::async_read and asio::read are active? Thank you. Kind regards.

2 2

Boost.Fusion macro expansion
by Robert Jones 01 Aug '17

01 Aug '17

Hi Peeps Can anyone tell me what's wrong with this? I think macro expansion is going awry, but I'm not sure why. Do I really have to typedef the map<...> type to keep Fusion happy? Thx. #include<string> #include<map> #include <boost/fusion/adapted/struct/define_struct.hpp> #include <boost/fusion/include/define_struct.hpp> BOOST_FUSION_DEFINE_STRUCT( (demo), curves, ((std::map<std::string, std::string>), futures) ((std::map<std::string, std::string>), credit_curves) ) int main( ) { return 0; } > make fusion.cpp|9 col 39| error: invalid declarator before ‘)’ token || ((std::map<std::string, std::string>), futures) Kind Regards Rob.

3 3

Ranges
by Robert Jones 29 Jul '17

29 Jul '17

I realise this isn't strictly about Boost, but I'd appreciate if someone could say a few words about the current state of ranges in the standard, Boost or elsewhere. I'm familiar with the current Boost.Range, but thought there was a newer and rather different range library from Eric Neibler which was Boost compatible but not formally part of Boost, is that right? Are either of these part of the C++ standard, either now or planned, or is there anything else planned for the standard? Thx. Kind Regards Rob.

2 1

[filesystem] Strange "Function not implemented" exception from directory_iterator
by Robert Dailey 28 Jul '17

28 Jul '17

I'm using a recursive_directory_iterator on an Android ARM device (armeabi-v7a, clang compiler, API 15, LLVM STL). The exception I get comes from directory_iterator_increment in operations.cpp (when it does the dir_itr_increment() call and checks the `temp_ec` variable, there is a throw below that). The what() of the exception says: boost::filesystem::directory_iterator::operator++: Function not implemented: "/data/ziosk/content/Common/DemoMode/font" I doubt this is a permissions issue. Which function is not implemented? Is this a POSIX / LIBC issue? I have no idea at this point...

2 4

Boost.ProgramOptions issues porting from 1.56 to 1.64
by Dominique Devienne 28 Jul '17

28 Jul '17

I have an SVN-like "multi-command" single executable, i.e. exe [global-options] command [command-options] It uses two levels of option parsing. First level: typedef std::vector<std::string> UnparsedArgs; inline boost::program_options::typed_value<UnparsedArgs>* anyArgs() { return boost::program_options::value<UnparsedArgs>(); } options_description global_all_desc("Global Options", columns); global_all_desc.add_options() ("command", txtArg(), "Command to execute") ("cmdargs", anyArgs(), "Arguments for command") ...; // from http://stackoverflow.com/questions/15541498 // see also https://gist.github.com/randomphrase/10801888 po::positional_options_description pos; pos .add("command", 1) .add("cmdargs", -1); variables_map global_args; parsed_options parsed = po::command_line_parser(argc, argv) .options(global_all_desc) .positional(pos) // for implicit command and cmdargs above .allow_unregistered() // for command-specific arguments. .run(); po::store(parsed, global_args); std::vector<std::string> cmd_args = po::collect_unrecognized( parsed.options, po::include_positional ); Second level parsed_options reparsed = po::command_line_parser(cmd_args) .options(cmd_all_desc) .run(); po::store(reparsed, args_); // JIRA FOO-426 for (const auto& option : reparsed.options) { if (option.position_key >= 0) { std::ostringstream oss; for (const auto& token : option.original_tokens) { oss << token << ' '; } auto s = oss.str(); s.resize(s.size() - 1); err() << "Error: Too many commands: " << command() << ' ' << s << endl; return 1; } } in this particular case, the option that fails is ( "new", txtArgOpt(), "Creates a new group" ), with txtArgOpt() as below: inline boost::program_options::typed_value<std::string>* txtArg() { return boost::program_options::value<std::string>(); } inline boost::program_options::typed_value<std::string>* txtArgOpt(const std::string& implicit_value = "") { return txtArg()->implicit_value(implicit_value); } in the case that fails, the first parsing works fine, and remains ["--new", "groupA"] as cmd_args. in 1.56, reparsed.options contains 1 element: - [0] {string_key="new" position_key=-1 value={ size=1 } ...} boost::program_options::basic_option<char> + string_key "new" std::basic_string<char,std::char_traits<char>,std::allocator<char> > position_key -1 int - value { size=1 } std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > [size] 1 __int64 [capacity] 1 __int64 + [0] "GroupA" std::basic_string<char,std::char_traits<char>,std::allocator<char> > + [Raw View] 0x0000000009fae6c0 {...} std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > * - original_tokens { size=2 } std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > [size] 2 __int64 [capacity] 2 __int64 + [0] "--new" std::basic_string<char,std::char_traits<char>,std::allocator<char> > + [1] "GroupA" std::basic_string<char,std::char_traits<char>,std::allocator<char> > + [Raw View] 0x0000000009fae6e0 {...} std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > * unregistered false bool case_insensitive false bool but in 1.64, it contains 2 elements: - [0] {string_key="new" position_key=-1 value={ size=0 } ...} boost::program_options::basic_option<char> + string_key "new" std::basic_string<char,std::char_traits<char>,std::allocator<char> > position_key -1 int - value { size=0 } std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > [capacity] 0 __int64 + [allocator] allocator std::_Compressed_pair<std::_Wrap_alloc<std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >,std::_Vector_val<std::_Simple_types<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >,1> + [Raw View] {...} std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > - original_tokens { size=1 } std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > [capacity] 1 __int64 + [allocator] allocator std::_Compressed_pair<std::_Wrap_alloc<std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >,std::_Vector_val<std::_Simple_types<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >,1> + [0] "--new" std::basic_string<char,std::char_traits<char>,std::allocator<char> > + [Raw View] {...} std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > unregistered false bool case_insensitive false bool - [1] {string_key="" position_key=0 value={ size=1 } ...} boost::program_options::basic_option<char> + string_key "" std::basic_string<char,std::char_traits<char>,std::allocator<char> > position_key 0 int - value { size=1 } std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > [capacity] 1 __int64 + [allocator] allocator std::_Compressed_pair<std::_Wrap_alloc<std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >,std::_Vector_val<std::_Simple_types<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >,1> + [0] "GroupA" std::basic_string<char,std::char_traits<char>,std::allocator<char> > + [Raw View] {...} std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > - original_tokens { size=1 } std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > [capacity] 1 __int64 + [allocator] allocator std::_Compressed_pair<std::_Wrap_alloc<std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >,std::_Vector_val<std::_Simple_types<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >,1> + [0] "GroupA" std::basic_string<char,std::char_traits<char>,std::allocator<char> > + [Raw View] {...} std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > unregistered false bool case_insensitive false bool This is copy/pasted from VS, sorry, a little hard to read, but basically 1.56 has #0 string_key = "new" position_key = -1 value = ["groupA"] original_tokens = ["--new", "groupA"] unregistered = false case_insensitive = false while 1.64 has 2 items: #0 string_key = "new" position_key = -1 value = [] original_tokens = ["--new"] unregistered = false case_insensitive = false #1 string_key = "" position_key = 0 value = ["groupA"] original_tokens = ["groupA"] unregistered = false case_insensitive = false as-if the arg to --new was now a positional parameter, instead of an optional arg to --new. And this triggers the work-around code that errors out I had put in place to catch cases when the old 1.56 code wouldn't complain about extra arguments (e.g. "exe ... cmd1 cmd1_args cmd2" would be silently accepted, despite the extra cmd2, or "exe ... cmd --arg1 read-only" was accepted, when "exe ... cmd --arg1 --read-only" was expected), and this even though the second parsing doesn't have .allow_unregistered(). I'm trying to understand what's going on; obviously there's some kind of semantic change with optional argument to switches. Could anyone shed some light on this please? I'm not sure how to proceed now. TIA, -DD

2 4