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

[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

error: 'function' in namespace 'boost' does not name a template type
by jupiter 28 Jul '17

28 Jul '17

Hi, Cannot I define a following boost function? Any workarounds? typedef boost::function<bool (const uint32_t, const std::shared_ptr<boost::asio::streambuf> &)> Subscriber_t; Thank you. Kind regards,

2 2

using ssl::context in boost 1.53 versions
by dipti Burli 27 Jul '17

27 Jul '17

Hi , I am currently using boost 1.53 version. cannot upgrade to latest version. Using ssl asio. Here is my requirement. I need to support tls1.1.and tls1.2 protocol in the server, but not tls1.0 . As there are no options for tls1.1. and tls1.2 ,and context is not present with relevant tls1.1 and tls1.2 versions, I created the ssl::context with tlsv1 method and used long ssl_disallowed = SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | SSL_OP_NO_TLSv1 | SSL_OP_NO_TLSv1_1 | SSL_OP_NO_TLSv1_2; ssl_disallowed &= ~SSL_OP_NO_TLSv1_2; ssl_disallowed &= ~SSL_OP_NO_TLSv1_1; SSL_CTX_set_options(myBoostSslcontext.native_handle(), ssl_disallowed|SSL_OP_SINGLE_DH_USE); But handshake seems to be failing for any other versions other than tlsv1. Can you please let me know how to I set the options so that my sserver can accept tls connections on tls1.1 and tls1.2 with boost version 1.53. Thanks in advance. Dipti

1 0

[mpl] [msm] wrong number of template arguments (120, should be at least 0)
by Alessandro Marzialetti 27 Jul '17

27 Jul '17

Hello, I'm working on a msm with a big transition table (120 elements) I already tried with #define BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS then #define BOOST_MPL_LIMIT_LIST_SIZE <custom value> But I can't go over a size of 50 (including "boost/mpl/vector/vector50.hpp") Any idea on how I can make a bigger table? Thanks, Alessandro <http://www.boost.org/doc/libs/1_63_0/libs/mpl/doc/refmanual/cfg-no-preproce…>

3 2

[Boost Graph Dijkstra Shortest Path]: Could not deduce template argument
by Choppin, Simon 26 Jul '17

26 Jul '17

Hello all, I use boost graph library for some point cloud processing and have had great success. However, I'm struggling to compile Dijkstra shorted path on MSVC v140. I am using boost library 1.53 and compiling in 64 bit. I used the example as a starting point but when I try to compile I get the error: Error C2784 'E boost::detail::get(boost::detail::underlying_edge_desc_map_type<E>,const boost::detail::reverse_graph_edge_descriptor<EdgeDesc> &)': could not deduce template argument for 'boost::detail::underlying_edge_desc_map_type<E>' from 'double *' I understand the fundamental problem that the template can't deduce type, however I'm struggling to source the problem. My graph type is: typedef adjacency_list < vecS, vecS, undirectedS, no_property, property <edge_weight_t, double> > WeightedGraph; Because I'm using MSVC I use the suggested non parameter name version: property_map<WeightedGraph, vertex_index_t>::type indexmap = get(vertex_index, GraphW); property_map<WeightedGraph, edge_weight_t>::type weightmap; std::vector<Vertex> p(num_vertices(GraphW)); std::vector<double> d(num_vertices(GraphW)); Vertex s = vertex(indices.first, GraphW); Vertex s_end = vertex(indices.second, GraphW); dijkstra_shortest_paths (GraphW, s, &p[0], &d[0], weightmap, indexmap, std::less<double>(), closed_plus<double>(), (double)(std::numeric_limits<double>::max)(), (double)0, Custom_visitor(s_end) ); I'm using a custom visitor to stop processing early as in this stackoverflow post: https://stackoverflow.com/questions/32047840/make-boost-dijkstra-algorithm-… Any ideas? All help greatly appreciated. Simon C

1 0

how to generate PDF formate documentations of Boost?
by easior 23 Jul '17

23 Jul '17

Hi, all in the list. I plan to build boost documentation in pdf format for latest version of boost. However, it's no luck to me even following the link: http://www.boost.org/doc/libs/1_40_0/doc/html/boostbook/getting/started.html. I can only find HTML formatted documentation for boost. I don't know what about the relationship between boost and doxygen. I also have no idea about the mechanism of the boostbook. Any suggection? Thanks in advance, Easior Lars

4 4

Boost Regex - Alternation documentation example
by Nick 21 Jul '17

21 Jul '17

According to the Boost Regex documentation for Alternation (http://www.boost.org/doc/libs/1_64_0/libs/regex/doc/html/boost_regex/syntax…) Quoting a piece of the documentation: ----- |abc is not a valid expression, but (?:)|abc is and is equivalent, also the expression: (?:abc)?? has exactly the same effect. ----- Is the last expression: (?:abc)?? correct? Why does it need two '?' operators instead of only one? If I try this expression with the input "abc" the Boost engine does not match "abc" as I'd have expected. However the expression: (?:abc)? matches as expected. Nick

2 2

MS controlled email domains - not going to work
by Michael Caisse 20 Jul '17

20 Jul '17

The irony in sending this message is that the people who need to see it probably wont get it. We are having trouble with hotmail.com, live.com, msn.com, and outlook.com. Microsoft is filtering the dedicated IP address used by the mail lists and most recently has responded with: Not qualified for mitigation [ip address] Our investigation has determined that the above IP(s) do not qualify for mitigation. These IP(s) have previously received mitigations from deliverability support, and have failed to maintain patterns within our guidelines, so they are ineligible for additional mitigation at this time. We have tried to explain multiple times that the IP address has a new owner but we seem to be stuck in almost an auto-response loop. We will continue to try and get service unblocked; however, I would recommend that you dump your MS controlled accounts for Boost mail lists and use another service. michael -- Michael Caisse Ciere Consulting ciere.com

2 1

[review][beast] Beast Review Results
by Michael Caisse 20 Jul '17

20 Jul '17

In an effort to get you all to just read this announcement sequentially, I will start with the result: Beast is ACCEPTED into Boost without conditions The entire community is served when the Boost review process works well and I would like to personally thank each of you who took your valuable time and worked to make Boost better. We had 21 formal reviews submitted from a demographic that included both seasoned participants and first-time reviewers. It is gratifying to have such participation for what some might see as a niche library. * Thank you Vinnie for your effort to assemble a high-quality package for review and for your responsiveness on the mail-lists. GitHub, and Slack. * Thank you to the individuals that submitted their first Boost review. * Thank you to the veteran contributors and authors for continuing to devote energy to the community. I found the discussion surrounding the library beneficial and I know that Vinnie walked away with actionable items to improve Beast. -------------------- The Stats: -------------------- While the review process is not exactly tallying up votes and casting a verdict, we can gain some insight of the general, gross-scale opinion of the library. Official reviews were received from: Reviewer Accept | Reject ------------------------------------------ * Zach Laine : X * Nik Bougalis : X * Artyom Beilis : X * Peter Dimov : X * Klemens Morgenstern : X * Glen Fernades : X * Marcel Ebmer : X * Scott Determan : X * Stanislav Karchebnyy : X * Michael Larson : X * Vadim Zeitlin : X * Jared Wyles : X * Niall Douglas : X * Barrett Adair : X * Gyorgy Szekely : X * Daniela Engert : X * Jens Weller : X * Phil Endecott : X * Bjorn Reese : X * Rüdiger Berlich : X * Christopher Kohlhoff : X Most of the reviewers agreed on the inclusion of Beast into Boost and at the same time that Beast isn't a great name for the library. (Just say Boost.Beast 10-times-fast). Vinnie has a FAQ item discussing the name and his continuing use is deliberate. He has heard the petitions to change and weighed them. -------------------- Concerns: -------------------- A variety of concerns and comments were made during the review. An impressive number of items were addressed in code or documentation during the review period itself. Some of the stated concern for rejection included: * Too many templates * Run-time polymorphism / OO would be better. * Library scope is too small and provides no real value to users - This is clearly one of those value judgements and for some users the not-in-scope nature of Beast made the feature set not compelling enough to use or have as a Boost library. Other users spent time converting existing projects to use Beast. This included projects previously running POCO, libcurl, and homegrown solutions. Beast has existing commercial and open-source users. The library clearly meets the needs of some users. * Premature optimization * Security concerns * Poor support for HTTP chunking - Vinnie proposed and then later made changes addressing the chunking concerns. Unfortunately, the reviewer with the complaint did not respond to multiple requests for feedback. * Licensing - Four files have dual licenses (BSL and another). Boost's legal counsel is reviewing the situation and we hope to have guidance by the end of this week. I have not placed a condition on the acceptance of Beast based on the legal feedback because Vinnie knows licensing issues must be remedied before the repository is merged into Boost. -------------------- The Upsides: -------------------- There were lots of great things said about the Beast package. Some of these include: * Great documentation * High quality implementation. * Thorough test suites * Already being used by commercial entities and others * Lots of successful real-life conversions of existing clients/servers * Extremely responsive developer (do you sleep Vinnie?) -------------------- An Author as much as a Library: -------------------- Accepting a library into Boost is also accepting an author. Boost authors have enormous latitude in the control and modifications of their libraries. Vinnie has shown dedication to addressing issues, listening to constructive input, making changes when appropriate, and protecting his vision of what the Beast is. I believe Vinnie will serve the community well as a contributor. -------------------- Final Thoughts: -------------------- Reviews are hard. It is hard to have your work torn apart and remain considerate. It is hard to repeat answers to previously asked questions. It is hard to explain specific use-cases and why it is important a library supports them. It is difficult to critique a large body of work. It is hard to stick with conversations to make overall improvements. I was impressed with the participants in the review. We are all opinionated and passionate -- likely a prerequisite to being part of the Boost community. Thank you all for making Boost better. I'm looking forward to seeing additional libraries and application built with Beast. -- Michael Caisse Ciere Consulting ciere.com

2 2

Re: [Boost-users] CMake Announcement from Boost Steering Committee
by Oliver Kowalke 20 Jul '17

20 Jul '17

I'm one of the maintainers of the CMake Boost support ( https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/FindBoost.cmake Roger, can Cmake be used for boost.context? Especially this library required to know the architecture, ABI, binary format, address model ... in order to select the right assembler?

3 3

Boost 1.65.0 Beta 1 Release Candidate 2
by Marshall Clow 19 Jul '17

19 Jul '17

The second release candidates for the 1.65.0 beta release are now available at: https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/boost_1_65_0_beta… https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/boost_1_65_0_beta… https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/boost_1_65_0_beta… https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/boost_1_65_0_beta… The SHA256 checksums are as follows: d54d29568c4e4933cbfe40a292b6cb84a7f68121e34f6a83f7d0f7c652b6b2d8 boost_1_65_0_beta1_rc2.7z 092676557513e992347d30dd0cd058fb8af2a401e5da4f4413f5b577852d726b boost_1_65_0_beta1_rc2.tar.bz2 31fa3c807e2205e18f7d5c74f77f540677f7b0937af1e37f595c137e1e87bf84 boost_1_65_0_beta1_rc2.tar.gz 83c8d8b76fa9591572226a1a49fd191d76db3011b52b907cbbc8d37d46213bd2 boost_1_65_0_beta1_rc2.zip This RC contains a single fix to the stacktrace library. As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. Thanks! -- The release managers

7 10

CMake Announcement from Boost Steering Committee
by Jon Kalb 18 Jul '17

18 Jul '17

The libraries produced by the Boost community have had a greater impact on the way that the C++ community writes code than any other library implementation. The focus of the Boost community will always be on the libraries, but it is undeniable that we are dependent on and often limited by the infrastructure of our trade. Years ago, the move to Git was contentious; yet, it was required to improve development. In a similar vein our build system has become an impediment for many developers and users, existing and prospective. Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers. We understand that the actual process of achieving the end goal will be long, time consuming, and not without its share of conflict. We also recognize that the Boost community is comprised of bright and passionate individuals that are eager to get involved and help get work done. The members of the Steering Committee have been encouraged by the discussions and activity surrounding CMake on the mailing lists over the years and know that many people have voiced visions. We hope that each of you rejoins the discussion to support this initiative and contributes to the common goal of improving Boost’s integration into the broader C++ ecosystem. For the Boost Steering Committee, Jon Kalb, Chair jonkalb(a)boost.org

8 7

Re: [Boost-users] CMake Announcement from Boost Steering Committee
by Oliver Kowalke 18 Jul '17

18 Jul '17

Cmake file for boost.context is missing support for segmented stack (split-stack), valgrind ...? Is the Cmake port is not complete?

1 0

Boost 1.65.0 Beta 1
by Marshall Clow 16 Jul '17

16 Jul '17

Boost release 1.65.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/> The SHA256 checksums are as follows: d54d29568c4e4933cbfe40a292b6cb84a7f68121e34f6a83f7d0f7c652b6b2d8 boost_1_65_0_beta1.7z 092676557513e992347d30dd0cd058fb8af2a401e5da4f4413f5b577852d726b boost_1_65_0_beta1.tar.bz2 31fa3c807e2205e18f7d5c74f77f540677f7b0937af1e37f595c137e1e87bf84 boost_1_65_0_beta1.tar.gz 83c8d8b76fa9591572226a1a49fd191d76db3011b52b907cbbc8d37d46213bd2 boost_1_65_0_beta1.zip Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

5 5

Boost Regex Back Reference Issue
by Nick 14 Jul '17

14 Jul '17

According to the Boost documentation for Back references (http://www.boost.org/doc/libs/1_64_0/libs/regex/doc/html/boost_regex/syntax…) which seems to be the same at least from 1.37 - 1.64. Quoting a piece of the documentation: ----- For example the expression: ^(a*).*\1$ Will match the string: aaabbaaa But not the string: aaabba ----- I'm finding two issues with the example cited. 1. It seems to me that the example of the string which should not match, should actually match. Ultimately, shouldn't the engine match the marked sub-expression with the first 'a' in order to satisfy the backreference? I tested this example with Oniguruma and with PHP's PCRE and they both matched the string noted here to not match. But also, since the marked sub-expression is (a*) then I wonder what the behavior would be if it couldn't make a match on 'a', since the '*' will allow for zero matches. In fact, it seems like everything in the pattern is effectively "optional" due to the '*' operator. I'm a novice with Perl, but unless I made a mistake, it will match unconditionally: print "It matches\n" if "aaabba" =~ /^(a*).*\1$/; It matches print "It matches\n" if "aaabbac" =~ /^(a*).*\1$/; It matches print "It matches\n" if "" =~ /^(a*).*\1$/; It matches print "It matches\n" if "x" =~ /^(a*).*\1$/; It matches print "It matches\n" if "xyz" =~ /^(a*).*\1$/; It matches print "It matches\n" if "123" =~ /^(a*).*\1$/; It matches 2. The other issue is that when I try this example with the string which is posted to not match, the Boost regex engine runs for a while and ultimately crashes with a memory error. (seems like it might be an endless loop of some sort). Is that a bug? Nick

3 4

boost::unordered_map takes too long when I have only two elements in it
by Ram 14 Jul '17

14 Jul '17

Hi, I am using a boost::unordered_set but I sometimes have just two elements in it. It takes a long time then. Is it wrong if I have too few elements? Thanks, Ram

3 3

rational - 1.64 version shear?
by Nicholas Devenish 14 Jul '17

14 Jul '17

With boost/rational.hpp, the code: boost::rational<int> a{1}; long b{1}; auto c{a * b}; Works fine up to 1.63.0, but fails to compile in 1.64+ on the multiplication with "error: invalid operands to binary expression". This seems to be due to some restructuring that changed the way multiplications are declared, which (as far as I can tell), meant the operation declaration became conditional on number of representable digits. This breaking change isn't listed on the release notes or the ::rational documentation, so I'm wondering if it was accidental and therefore a bug (whose behaviour might change), or a deliberate change to prevent downcasting and just undocumented? Nick (I've come onto a project stuck on 1.56 and trying to update it)

2 1

⁨[process] problem with boost::process::on_exit
by Sandy Martel 14 Jul '17

14 Jul '17

The code below outputs: 1- child about to sleep for 2s 2- child about to sleep for 4s 3- child finish sleeping for 2s 6- sleep 4s child finished 5- child finish sleeping for 4s 4- sleep 2s child finished in a posix environment. I would expect the output to be in-order, looks like I get the wrong on_exit notification for the child processes I launch. Q: is this a bug or am I doing something wrong ? What is the correct way to get notified of specific process termination ? Regards, Sandy. code: #include <boost/process.hpp> #include <boost/asio.hpp> #include <thread> #include <iostream> int main( int argc, char **argv ) { if ( argc > 2 && strcmp( argv[1], "sleep" ) == 0 ) { auto s = atoi(argv[2]); std::cout << (s/2) << "- child about to sleep for " << s << "s" << std::endl; std::this_thread::sleep_for( std::chrono::seconds(s) ); std::cout << (s+1) << "- child finish sleeping for " << s << "s" << std::endl; return 0; } namespace bp = boost::process; boost::asio::io_service ios; // launch a child that will sleep for 2s auto c1 = bp::child( argv[0], "sleep", "2", ios, bp::on_exit( [](int, const std::error_code&) { std::cout << "4- sleep 2s child finished" << std::endl; }) ); // wait a bit, make sure the child startup for my test std::this_thread::sleep_for( std::chrono::milliseconds(10) ); // launch a child that will sleep for 4s auto c2 = bp::child( argv[0], "sleep", "4", ios, bp::on_exit( [](int, const std::error_code&) { std::cout << "6- sleep 4s child finished" << std::endl; }) ); // wait for the notifications ios.run(); }

1 0

[serialization] "Archive" type turns into abstract class during save/load!
by r＠primef.actor 13 Jul '17

13 Jul '17

In a member load function function I call a static method that loads another archive file, i.e. something like this: ```c++ struct Bar; struct Foo { std::shared_ptr<Bar> data; template <class Archive> void load(Archive& archive, const unsigned /*version*/) { std::string key; archive >> key; data = Bar::loadSomewhere<Archive>(std::move(key)); } }; struct Bar { template <class Archive> std::shared_ptr<Bar> loadSomewhere(std::string key) { std::ifstream input(key); Archive ar(input); std::shared_ptr<Bar> bar(new Bar()); ar >> *bar; return bar; } }; ``` The problem is that `Bar::loadSomewhere` is passed a `boost::archive::polymorphic_iarchive`, while I invoke the serialization library with a `boost::archive::xml_iarchive`. This is an abstract class, so I can't instantiate it! So somewhere down the road the `xml_iarchive` is turned into a `polymorphic_iarchive`. I would like to prevent this from happening, because I instantiate an `Archive` object in the `Bar::loadSomewhere` function. How can I get around this problem?

1 0

Re: [Boost-users] Boost 1.65.0 Beta 1 Release Candidate 2
by Matthieu Brucher 11 Jul '17

11 Jul '17

This happens a lot when people develop on gcc or visual studio and then try building with clang. Having a function and a class with the same name is bound to generate errors. So properly should be tagged as a bug. Le 11 juil. 2017 11:14 AM, "Raffi Enficiaud via Boost-users" < boost-users(a)lists.boost.org> a écrit : Le 11.07.17 à 02:14, Marshall Clow via Boost-users a écrit : The second release candidates for the 1.65.0 beta release are now > available at: > > > https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/ > boost_1_65_0_beta1_rc2.7z > > https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/ > boost_1_65_0_beta1_rc2.tar.bz2 > > https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/ > boost_1_65_0_beta1_rc2.tar.gz > > https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/ > boost_1_65_0_beta1_rc2.zip > > The SHA256 checksums are as follows: > > d54d29568c4e4933cbfe40a292b6cb84a7f68121e34f6a83f7d0f7c652b6b2d8 > boost_1_65_0_beta1_rc2.7z > 092676557513e992347d30dd0cd058fb8af2a401e5da4f4413f5b577852d726b > boost_1_65_0_beta1_rc2.tar.bz2 > 31fa3c807e2205e18f7d5c74f77f540677f7b0937af1e37f595c137e1e87bf84 > boost_1_65_0_beta1_rc2.tar.gz > 83c8d8b76fa9591572226a1a49fd191d76db3011b52b907cbbc8d37d46213bd2 > boost_1_65_0_beta1_rc2.zip > > > This RC contains a single fix to the stacktrace library. > > As always, the release managers would appreciate it if you download > the candidate of your choice and give building it a try. Please report > both success and failure, and anything else that is noteworthy. > > Thanks! > > -- The release managers > Hi, I have this error during the build on OSX. Built with: ./b2 cxxflags="-std=c++11 -stdlib=libc++" linkflags="-stdlib=libc++" --without-log --layout=versioned install ...on 14200th target... common.mkdir bin.v2/libs/fiber/build/darwin-4.2.1/release/threading-multi common.mkdir bin.v2/libs/fiber/build/darwin-4.2.1/release/threading- multi/numa darwin.compile.c++ bin.v2/libs/fiber/build/darwin-4.2.1/release/threading- multi/numa/pin_thread.o libs/fiber/src/numa/pin_thread.cpp:23:10: warning: pin_thread() not supported [-W#pragma-messages] # pragma message "pin_thread() not supported" ^ 1 warning generated. darwin.compile.c++ bin.v2/libs/fiber/build/darwin-4.2.1/release/threading- multi/numa/topology.o libs/fiber/src/numa/topology.cpp:23:10: warning: topology() not supported [-W#pragma-messages] # pragma message "topology() not supported" ^ libs/fiber/src/numa/topology.cpp:27:14: error: use of undeclared identifier 'topology'; did you mean 'fibers::numa::topology'? std::vector< topology > topology() { ^~~~~~~~ fibers::numa::topology ./boost/fiber/numa/topology.hpp:38:21: note: 'fibers::numa::topology' declared here std::vector< node > topology(); ^ libs/fiber/src/numa/topology.cpp:27:14: error: template argument for template type parameter must be a type std::vector< topology > topology() { ^~~~~~~~ /Applications/Xcode8.1.app/Contents/Developer/Toolchains/Xco deDefault.xctoolchain/usr/bin/../include/c++/v1/vector:456:17: note: template parameter is declared here template <class _Tp, class _Allocator = allocator<_Tp> > ^ 1 warning and 2 errors generated. "g++" -ftemplate-depth-128 -O3 -Wall -dynamic -gdwarf-2 -fexceptions -Wno-inline -fPIC -arch x86_64 -std=c++11 -stdlib=libc++ -DBOOST_ALL_NO_LIB=1 -DBOOST_CONTEXT_DYN_LINK=1 -DBOOST_DISABLE_ASSERTS -DBOOST_FIBERS_DYN_LINK=1 -DBOOST_FIBERS_SOURCE -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_DYN_LINK=1 -DNDEBUG -I"." -c -o "bin.v2/libs/fiber/build/darwin-4.2.1/release/threading-multi/numa/topology.o" "libs/fiber/src/numa/topology.cpp" ...failed darwin.compile.c++ bin.v2/libs/fiber/build/darwin -4.2.1/release/threading-multi/numa/topology.o... _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users

2 1

Boost 1.65.0 Beta 1 Release Candidate 1
by Marshall Clow 09 Jul '17

09 Jul '17

The release candidates for the 1.61.0 release are now available at: https://dl.bintray.com/boostorg/beta/boost_1_65_0_beta1_rc1.7z https://dl.bintray.com/boostorg/beta/boost_1_65_0_beta1_rc1.tar.bz2 https://dl.bintray.com/boostorg/beta/boost_1_65_0_beta1_rc1.tar.gz https://dl.bintray.com/boostorg/beta/boost_1_65_0_beta1_rc1.zip The SHA256 checksums are as follows: cd7429340bb4aae38e0ad2e9f59c39e66335302c41577956123e55fc1e2a28ee boost_1_65_0_beta1_rc1.7z fda076f7b3c994524d9cd41926c72f4a9b7c017bef310a055956fdd0bed7c358 boost_1_65_0_beta1_rc1.tar.bz2 0d1473041f7a9fa9ce1e256c870cc52af6f98abf723cf4f1ac61c2b45f45d38a boost_1_65_0_beta1_rc1.tar.gz f45bbb75b84cdc0c66f8a571d77c518cfbac076d7a6fc7937c4812f0f242a792 boost_1_65_0_beta1_rc1.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. Thanks! -- The release managers

2 1

building for msvc-14.1
by Isaac Lascasas 09 Jul '17

09 Jul '17

Hello I have serious problems building boost for vs2017. My win10 install has just visual studio community 2017 installed right now, with windows SDK 10.0.15063.0 and 8.1. I run the vs2017 x64 native prompt and then I do something like this: b2 -j12 toolset=msvc-14.1 address-model=64 architecture=x86 link=static threading=multi runtime-link=shared --build-type=minimal stage --stagedir=stage/x64 some headers give weird stl container errors: c:\libs\boost_1_64_0__64\boost/archive/detail/basic_serializer_map.hpp(47): error C2039: 'set': is not a member of 'std' Thanks, Isaac.

1 0

[review] Mp11 review starts in one week
by Bjorn Reese 08 Jul '17

08 Jul '17

The formal review of Peter Dimov's Mp11 library is scheduled for July 15 - July 24, 2017 [1]. Mp11 is a C++11 metaprogramming library for compile-time manipulation of data structures that contain types. It’s based on template aliases and variadic templates and implements the approach outlined in the article "Simple C++ metaprogramming" [2] and its sequel [3]. These articles are useful background information for the review. * Mp11 aims to make simple usage simple, and to support complex usage without complicating the simple use cases. * Mp11 works on any type-list, whether its own type-list mp_list, or standard type-lists such as std::tuple and std::variant, or user-defined type-lists. * Mp11 works with any meta-function, such as C++11 or Boost type-traits, or user-defined type-traits. Mp11 can be found here: * Documentation: https://rawgit.com/pdimov/mp11/master/doc/html/mp11.html * Source code: https://github.com/pdimov/mp11/tree/master [1] http://www.boost.org/community/review_schedule.html [2] http://pdimov.com/cpp2/simple_cxx11_metaprogramming.html [3] http://pdimov.com/cpp2/simple_cxx11_metaprogramming_2.html

1 0

Serialization support for small_vector
by Brian Wood 07 Jul '17

07 Jul '17

Shalom I've added support for small_vector to the C++ Middleware Writer. While testing the support, I got a warning about dereferencing a type-punned pointer breaking strict-aliasing rules. That was on line 340 of small_vector.hpp. I was using g++ 7.1 on FreeBSD/ TrueOS. I used the following "Middle" code for testing: message-lengths variable example_messages -out (message_id_8, ::boost::container::small_vector<int32_t,30>) -in (::boost::container::small_vector<int32_t,30>) } >From what I could tell the serialization/deserialization worked fine. If small_vector were broken out into a separate library that would be helpful from my perspective. It would make it easier for me to add small_vector to my example code. Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

2 1