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

[interprocess] Determine size of managed_shared_memory
by Kai Benndorf 12 Oct '19

12 Oct '19

Hi all, I want to create a managed_shared_memory in exactly the size I needed. Therefore I do something like this: size = sizeof( common_managed_shared_memory ); size += sizeof( MyClassInSharedMem ); managed_shared_memory segment(create_only, "name", size ); MyClassInSharedMem allocates itself some memory by segment->allocate(). I added this also to the size, but get a boost::interprocess::bad_alloc exception on allocating this additional memory. Are there some magic bytes I forgot to add? Many thanks in advance Kai

3 2

Fatal Error LNK1104: cannot open file
by Cg K 30 Jul '19

30 Jul '19

I posted this issue originally on the boost list, largely to inform that I have been able to compile boost_1_71_0_b1_rc1 using VS 2019. See that post here: <https://lists.boost.org/Archives/boost/2019/07/246678.php> I moved this post here because I think my subsequent problem has to do with setting up Visual Studio 2019. I have followed the Getting Started in Windows <https://www.boost.org/doc/libs/1_70_0/more/getting_started/windows.html> tutorial and was able to build the simple program, aka the header only project, in VS. It compiled and ran fine. I then built the project that links your program to the Boost Library described in the tutorial. I received the following message when I compiled as x64. 1>LINK : fatal error LNK1104: cannot open file 'libboost_regex-vc142-mt-gd-x64-1_71.lib' As you can see in my original email post referred to above, I built another simple program based upon a youtube video and on VS2017 and while it compiled in the youtube video, I received a the same linker error, LNK1104 message as well. Since the file referred toin the LNK1104 error has the prefix lib, it appears that VS is looking for a static library. I built boost as shared from the Develop command line using the command. .\bj2 link=shared . This method apparently worked in VS2017 but I can not replicate it in VS2019. What am I missing?

2 2

Result of out_ptr review.
by Zach Laine 29 Jul '19

29 Jul '19

I've compiled the results of the reviews of out_ptr during its recent review. Unfortunately, out_ptr is NOT ACCEPTED, though many of the reviewers indicated interest in seeing it come back in some future form. I counted these formal reviews: Andrey Semashev: reject Louis Dionne: accept David Sankel: reject Phil Endecott: reject Glen Fernandes: reject Gavin Lambert: reject Thanks to all of the above reviewers, and to all those who contributed to the ongoing discussions surrounding out_ptr, even if they did not have time for a full review. Points against out_ptr raised during the review: - Many reviewers indicated their puzzlement that this library was proposed at all, since they had never seen enough calls to C APIs in their own code to motivate the need for out_ptr. - Some reviewers who did find the motivating cases of the library compelling, still said that they would prefer to write wrappers instead of using something like out_ptr. - Multiple reviewers want the library to provide error-reporting help (it currently does not). In particular, for c_func(out_ptr(p)), there was a concern about whether p is assigned a value, when c_func() returns a failure-status. - There was concern from several reviewers about the fact that out_ptr's types' dtors may throw, though this is only limited to the use of out_ptr with shared_ptr and similar smart pointers. In particular, non-unique_ptr uses will never throw in out_ptr's types' dtors, unless the user provides a throwing deleter. - Multiple reviewers disagreed with the use of template specialization as a customization mechanism. - There was widespread concern about the use of potentially UB-invoking tricks to get max performance out of the implementation. - Many reviewers wanted a more typical Boost tutorial introduction in the documentation. Now please permit me a digression. The library attempts to take a call that looks like this (simplest call possible): // CASE 0 foo * new_foo; TODO if (!create_foo(&new_foo)) { // etc. ... } And turn it into something as close as possible to this: // CASE 1 std::unique_ptr<foo> new_foo; if (!create_foo(new_foo)) { // etc. ... } out_ptr does a great job of this lexically: // CASE 2 std::unique_ptr<foo> new_foo; if (!create_foo(out_ptr(new_foo))) { // etc. ... } If you have not written thousands of lines of code that look like case 0, stop for a second and consider what it would be like to drop those thousands of raw pointers into your code, and how much you would like to replace them all with unique_ptrs. Now consider what it would take you to write all the wrapping functions necessary to make those thousands of calls look like case 1. You may make tooling to generate the wrappers, and that's time consuming. Writing it by hand is even more so. out_ptr also has the nice property that using it as I have above with unique_ptr does not change the meaning of the code, except to ensure that new_foo is guaranteed to be treated in a RAII manner. Thus we get increased exception safety, memory leak mitigation, etc. -- y'know, all that RAII stuff. If out_ptr is implemented well, case 2 should produce nearly identical object code to case 0, except that case 2 handles calling new_foo's dtor at the right time. Note that because of this, you have the same relationship to the C API in all three cases. That is, you need to check for the success value returned from create_foo(), and you need to know what create_foo()'s contract is in the face of errors -- did it write to new_foo or not? out_ptr is how you get from raw pointers to RAII ones, not how you solve all programming problems related to calling functions. Hopefully that motivates the use case for out_ptr, even if you don't need it in your own code. Hopefully that also allays concerns that out_ptr is not doing enough -- doing more is outside the library's scope. Now, on to exceptions in out_ptr's types' dtors. I heard a lot of discussion about this during the review. To me, concerns about what happens when an out_ptr or an inout_ptr throws in its dtor misses the point entirely, because it is concerned with fixing corner cases we should not even care to support. Instead of worrying about the semantics of exceptions in those kinds of situations, we should instead be asking why we want to support user code like this: ... } catch { create_foo(in_out_ptr(my_shared_ptr_to_a_foo)); ... } In other words, we don't really care about the dtor exceptions, unless: - there is an active exception already, and - we are also calling a C API to create a new object (a possible, but certainly atypical thing to do when handling an exception), and - we're catching this new object in a shared_ptr-like smart pointer that might throw on construction. Who writes code like that? Few people, perhaps none. It's not impossible to see code like that, but until there are well-motivated cases for this, maybe leave it for a later version of the library. In other words, the question should have been "Why support anything other than nothrow-constructible RAII types like unque_ptr?" Note that I find this argument compelling for the WG21-facing version of this work too. To summarize: I think the first four bullet points listed at the beginning of this post are, or could easily be made to be, irrelevant. So, that leaves some issues still outstanding: - figure out how to provide customization points (I'm actually fine with the current approach...), - eliminate the UB-dangerous code, or make it opt-in, - rework the tutorial portion of the docs, and - many assorted doc cleanups. That does not seem like an unreasonable amount of stuff to resolve in post-review acceptance readiness. I bring all this up because I do in fact hope that JeanHeyd brings this back for a future review, and I hope that my arguments here will convince some of you that this library is a useful thing to have around. I waited until now to say any of these things in an attempt to remain impartial during the review; I've been bothered by seeing previous review managers clearly represent a pro-acceptance position from the start. Thanks to JeanHeyd for his submission. A no-vote from this group is a tough thing, and I hope that the feedback he has received takes some of the sting out. Zach

6 5

Need some help with Boost.Build
by Maarten Verhage 29 Jul '19

29 Jul '19

Dear Boost.Build expert, I do have Boost 1.69 and was able to build from the sources with Mingw-w64 gcc 8.1 on Windows 7. That was for boost itself, but now I need to build the tests for the Boost library Spirit (the parser). I cannot get this to work. My Boost.Build version is 2018.02-git. According to Boost.Build paragraph 3.3 Configuration, the option "b2 --debug-configuration" gives info how my boost.build is configured. In the folder <boost-build>\example\hello the output of "b2 --debug-configuration" looks fine. But when I run from the folder <boost-spirit-develop>\test "b2 --debug-configuration" the output contains: error: Could not find parent for project at '.'. So in the folder <boost-spirit-develop>\test I rename Jamfile to Jamroot.jam. Now with "b2 --debug-configuration" I get: output.txt (attachtment of this email) Also when I try to build the tests it I gets the same error messages strarting from: config.jam: No such file or directory How do I solve this? Best regards, Maarten Verhage

1 0

boost::test observing failures
by John Foster 27 Jul '19

27 Jul '19

I am using boost test within a home-grown GUI, and want to access test results (e.g. the failure message and location when a test fails) The unit_test::test_observer class provides the virtual method: void assertion_result(boost::unit_test::assertion_result) However, unit_test::assertion_result is just an enum indicating success or failure. From there, I cannot see how to access further information about the test result. The framework also provides the class test_tools::assertion_result, which encapsulates an error message, but this only appears to be used for evaluating pre-conditions. (I would have expected this type to be the argument to unit_test::test_observer::assertion_result). The log output classes appear to provide more information on test results. These are implemented as streams, which makes it non-trivial to extract test result data. Does anyone know how I can access the information on test results - success/failure, the test code, the location, etc? Thanks John John Foster [cid:image001.png@01D3CC10.659716E0]<http://en.wikipedia.org/wiki/Qantassaurus> Associate Director, Quant Analysis Regulatory Modelling Credit Risk Analytics and Portfolio National Australia Bank Level 15, 500 Bourke St, Melbourne VIC 3000 Tel: +61 (0)3 8641 5228 Email: john.x.foster(a)nab.com.au<mailto:John.X.Foster@nab.com.au> ________________________________ The information contained in this email communication may be confidential. If you have received this email in error, please notify the sender by return email, delete this email and destroy any copy. Any advice contained in this email has been prepared without taking into account your objectives, financial situation or needs. Before acting on any advice in this email, National Australia Bank Limited (NAB) recommends that you consider whether it is appropriate for your circumstances. If this email contains reference to any financial products, NAB recommends you consider the Product Disclosure Statement (PDS) or other disclosure document available from NAB, before making any decisions regarding any products. If this email contains any promotional content that you do not wish to receive, please reply to the original sender and write "Don't email promotional material" in the subject.

2 1

[boost] [release] Boost 1.71.0 Beta 1 - déjà vu
by Michael Caisse 22 Jul '19

22 Jul '19

Note: The previous email announcement still had the rc1 tag in the filenames. This version of beta1 is identical in content to beta1 rc1. Boost release 1.71.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.71.0.beta1/source/> The SHA256 checksums are as follows: 451adc4f199c73e995e541f38c4dbd51faf4ce0db15537136ffd5213a1be5e55 boost_1_71_0_b1.7z a93d7066fc1514995aec0e726532a219447dd39b0ffa7cb97ca5736f16b0488b boost_1_71_0_b1.tar.bz2 34743b80466463e0c1b7fc71b677f326bdc242fe0b87a9c1599b6f7ea6e5c0cb boost_1_71_0_b1.tar.gz 5cd448bddc8394469391306e0ccada0a8f88c5c6cf8ec775ddf8e56adef8bbc2 boost_1_71_0_b1.zip For details of what's in the release, see <http://www.boost.org/users/history/version_1_71_0.html>. Note: Having some trouble getting the web page updated... check back with it soon. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

4 4

trying to create a vector of histograms
by damien＠khubla.com 20 Jul '19

20 Jul '19

Hi all, As the subject says, I'm trying to create a vector of histograms. This needs to be a member variable of a class so I need to get the types right in the declaration. I keep getting type conversion errors when I pass the axis to the constructor, so I'm trying a non-vector example. Here's the base code: using UU = boost::histogram::unlimited_storage<std::allocator<double> >; using AA = std::tuple<boost::histogram::axis::variable<double> >; AA ax; boost::histogram::histogram<AA, UU> histo; histo = boost::histogram::histogram(ax); //this has a conversion problem The error on VS 2017 is: error C2440: '<function-style-cast>': cannot convert from 'boost::histogram::axis::variable<double,boost::use_default,boost::use_defau lt,std::allocator<_Ty>>' to 'boost::histogram::histogram<boost::histogram::axis::variable<double,boost:: use_default,boost::use_default,std::allocator<_Ty>>,boost::histogram::defaul t_storage>' with [ _Ty=double ] note: No constructor could take the source type, or constructor overload resolution was ambiguous I can see that the types are different, but no matter what I do with the template arguments of the axis type I still get that error. Can anyone help? Damien

1 1

[release] Boost 1.71.0 Beta 1
by Michael Caisse 19 Jul '19

19 Jul '19

Boost release 1.71.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.71.0.beta1.rc1/source/> The SHA256 checksums are as follows: 451adc4f199c73e995e541f38c4dbd51faf4ce0db15537136ffd5213a1be5e55 boost_1_71_0_b1_rc1.7z a93d7066fc1514995aec0e726532a219447dd39b0ffa7cb97ca5736f16b0488b boost_1_71_0_b1_rc1.tar.bz2 34743b80466463e0c1b7fc71b677f326bdc242fe0b87a9c1599b6f7ea6e5c0cb boost_1_71_0_b1_rc1.tar.gz 5cd448bddc8394469391306e0ccada0a8f88c5c6cf8ec775ddf8e56adef8bbc2 boost_1_71_0_b1_rc1.zip For details of what's in the release, see <http://www.boost.org/users/history/version_1_71_0.html>. Note: Having some trouble getting the web page updated... check back with it soon. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

2 4

boost::filtered_graph filtering on vertex color... if I only had a colormap
by Brian Davis 19 Jul '19

19 Jul '19

Lets say I have a graph g (of type graph_t) and a color map (boy I wish I had a colormap): typedef boost::property_map<graph_t, boost::vertex_color_t>::type color_map_t; or is it? auto indexmap = boost::get(boost::vertex_index, g); auto colors = boost::make_vector_property_map<boost::default_color_type>(indexmap); or maybe? auto indexmap = boost::get(boost::vertex_index, g); auto colors = boost::make_vector_property_map<boost::vertex_color_t>(indexmap); or possibly some goop found on the internet? boost::make_iterator_property_map(color_map.begin(), boost::get(boost::vertex_index, data_->g), color_map[0]) or other internet goop? typedef boost::property_map<GraphType, boost::vertex_color_t>::type color_map_t; color_map_t colorMap; boost::color_map(colorMap)) or other internet goop?? std::vector<int> colorMap(num_vertices(g), boost::white_color); so confused... (certainly not surprised why bgl is not a part of stl) Can someone help explain the various types and ways of specifying colormaps and the logic for each way and means? and a function (if I could get that far without VS syntax highlighter going bonkers and gobs of compiler errors.. you know the type): make_pretty(g, colormap ) which colors the graph colormap and a filter struct for boost::filtered_graph<Graph, EdgePredicate, VertexPredicate> (where I wonder why if I only want to filter vertices I have to set boost::keep_all for EdgePredicate... sigh... I know the answer... and also know how long it found me to find/figure out boost::keep_all - and if you are looking for boost::keep_all and found it here... your welcome ;-) ) and modifying (probably incorrectly) boost::filtered_graph example to: template <typename ColorMap> struct vertex_color_filter_eq { vertex_color_filter_eq() { } vertex_color_filter_eq(ColorMap colormap/*, boost::default_color_type c*/) : m_colormap(colormap)/*, m_c(c)*/ { } template <typename Vertex> bool operator()(const Vertex& v) const { return 0 < get(m_colormap, v); //return c < get(m_colormap, v); } ColorMap m_colormap; //boost::default_color_type m_c; }; auto indexmap = boost::get(boost::vertex_index, g); auto colors = boost::make_vector_property_map<boost::default_color_type>(indexmap); // some where here I would call make_pretty(g, colors) typedef property_map<graph_t, boost::vertex_color_t>::type ColorMap_t; vertex_color_filter<ColorMap_t> filter(colors); // boost::filtered_graph<graph_t, boost::keep_all, VertexPredicate> boost::filtered_graph<graph_t, boost::keep_all, vertex_color_filter> fg(g, filter); // Later say if I could get it compile and better if it compiled and worked I could move on and auto color = boost::red_color; typedef property_map<graph_t, boost::vertex_color_t>::type ColorMap_t; vertex_color_filter<ColorMap_t> filter(colors, color); boost::filtered_graph<graph_t, boost::keep_all, vertex_color_filter> fg(g, filter); Maybe if I color them yellow, I can then reach the wizard pull back the curtain and ask how to create a color map... If I only had a color map.

4 6

How can I create an internal and modifiable color_map for boost DFS?
by Juergen 19 Jul '19

19 Jul '19

Hello, everybody, at the moment I am really lost. The problem is to create the color map that can be used in Depth_First_Search. A special feature that I have is that I want to change the Vertex color of DFS to modify the DFS. For example like this: If I make the color map global and pass it to the visitor, everything works: If the color map is not global but external, I can write the map, but it is not the same as the DFS color map and therefore I cannot manipulate the DFS algorithm: I then tried to create an internal map and work with the get() and put() functions, but I didn't succeed: I'd be so grateful if you'd give me a hint. -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Users-f2553780.html

1 0