April 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

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

[Boost.Asio coroutines] Question about HTTPServer4 examples
by daniil＠daniil.it 01 May '19

01 May '19

1 1

Using Boost 1.63 and 1.66 together with GNU unique global objects
by Jamie Jason 30 Apr '19

30 Apr '19

Apologies if this is a newbie question, but I have done my best to search Google, etc., and haven't been able to find a solution. The project I am working on uses Boost 1.63 statically linked and a third-party shared library that uses Boost 1.66 statically linked on CentOS 7. For reasons that are beyond my control, these are the versions that must be used. I am running into a problem with g++ 4.5.8 and the GNU extension to ELF for unique global symbols. Take as example the function get_netdb_category() in boost/asio/impl/error.ipp. The function has a static boost::asio::error::detail::netdb_category object that it returns a const reference to. When I use nm to inspect the main executable the symbol appears in the data segment and the type for boost::asio::error::detail::netdb_category()::instance is "u", which indicates that the compiler has marked this as a globally-unique symbol. The problem occurs when the loader loads the third-party shared library. Because the symbol boost::asio::error::detail::netdb_category()::instance has been marked as unique in the shared library as well (verified by running readelf on the .so), the loader decides that it will simply use the one from the executable. Because the shared library's version of the object is larger than the executable's version, when it is constructed it overwrites the 16 bytes beyond the end of the executable's object, trashing the contents of the data segment that were there previously. I tried using the -fno-gnu-unique flag when compiling our executable, but that doesn't fix the problem - it marks the symbol as weak in the main executable, but the shared library, because I cannot re-compile, still has the symbol marked as unique. I tried using dlopen with RTLD_LOCAL and that fixes the problem of overwriting the main executable's memory, however the corresponding symbols in the shared library have pointers back into the main executable's data segment (where the corresponding netdb_category static lives), which means that when if the shared library accesses these objects it will be following invalid pointers as it will overlay a larger v1.66 object onto a smaller v1.63 object. Has anyone encountered a problem like this? And, if so, did you find a good solution? Much thanks, Jamie

4 4

[locale] gettext functions: std::locale default argument not working
by Jeanette C. 29 Apr '19

29 Apr '19

Hey hey, it appears that the std::locale const &loc=std::locale() argument of the gettext functions for direct message translation doesn't properly pick up the program's global locale. Assume that messages have been extracted and translated. Consider the code snippet below: ... boost::locale::generator gen; std::locale loc = gen("de_DE"); std::locale::global(loc); // std::locale loc2; // will also work as argument to gettext string s = boost::locale::gettext("Hello world"); // output "Hello world" string t = boost::locale::gettext("Hello world",loc); // output "Hallo Welt" ... I am on boost 1.69.0-2, Arch Linux package, gcc 8.2.1, libstdc++ 6.0.25 (taken from the dynamic library filename), this is distributed with the GCC package. I'd appreciate any hint to solve this, since it would mean a lot of code editing otherwise. Best wishes and thanks, Jeanette -- * Website: http://juliencoder.de - for summer is a state of sound * SoundCloud: https://soundcloud.com/jeanette_c * Youtube: https://www.youtube.com/channel/UCMS4rfGrTwz8W7jhC1Jnv7g * GitHub: https://github.com/jeanette-c * Twitter: https://twitter.com/jeanette_c_s Cinderella's got to go <3 (Britney Spears)

1 0

[locale] Using generator with std::locale always yields name *
by Jeanette C. 29 Apr '19

29 Apr '19

Hey hey, When I use the boost::locale::generator to initialise an std::locale the std::locale.name() always yields "*". Examples: ... boost::locale::generator gen; std::locale loc = gen("en_US"); std::cout << loc.name(); ... output: * Whereas using the std::locale constructor with const char * yields the proper name: ... std::locale loc("en_US"); std::cout << loc.name(); ... Output: en_US I am running on Arch Linux, with Boost version 1.69.0-2 (the latest version in the official Arch package repositoy). Is there a caveat I overlooked or is there another way around this behaviour? One word of praise: the Boost locale library gave me the first pleasant experience of using localisation. I love the interface and think it very understandable even for a programmer of only mediocre level like myself. So: thank you! Best wishes, Jeanette -- * Website: http://juliencoder.de - for summer is a state of sound * SoundCloud: https://soundcloud.com/jeanette_c * Youtube: https://www.youtube.com/channel/UCMS4rfGrTwz8W7jhC1Jnv7g * GitHub: https://github.com/jeanette-c * Twitter: https://twitter.com/jeanette_c_s I thought love was just a tingling of the skin <3 (Britney Spears)

2 2

Windows batch file to build for multiple compiler versions
by Kenneth Porter 25 Apr '19

25 Apr '19

Here's the batch file I use to build the binary libraries for each new version of Boost for all the compilers and architectures my own library supports. Suggestions for improvements are welcome. Just define the boost_root environment variable and run it. https://gist.github.com/SpareSimian/2a0f1fd1718d81ce2441218ded776778

2 1

[MP11] Loosing const-qualification on type result with GCC 4.8 only
by Mateusz Loskot 25 Apr '19

25 Apr '19

Hi, I prepared a lenghty MWE which reproduces my problem with type manipulation using MP11 that for some reason looses const-qualification on a ::type result Here it is at https://godbolt.org/z/eCsakP and copied below. I hope the XXXXXX comments make sense and important static assertions in the main() at the bottom explain what is the expected result. ``` #include <boost/mp11.hpp> #include <cstdint> #include <type_traits> namespace mp11 = boost::mp11; template <typename BitField, int FirstBit, int NumBits, bool IsMutable> struct bit_range_reference { /* long definition, irrelevant */ }; template <typename BitField, typename FirstBit, typename NumBits> struct bit_range_reference_type { using type = bit_range_reference < BitField, FirstBit::value, NumBits::value, true > const; // XXXXXX Why this const gets lost with GCC 4.8 XXXXXX }; template <typename BitField, typename RangeBitSizes> class bit_range_reference_list { template <typename FirstBit, typename NumBits> using reference_type = typename bit_range_reference_type < BitField, FirstBit, NumBits >::type; // XXXXXX Should carry the const, shouldn't? GCC >4.8 do. // If RangeBitSizes is mp11::mp_list_c<int,7,7,2> // then first_bit_list will be mp11::mp_list_c<int,0,7,14,16> using first_bit_list = mp11::mp_fold_q < RangeBitSizes, mp11::mp_list<std::integral_constant<int, 0>>, mp11::mp_bind < mp11::mp_push_back, mp11::_1, mp11::mp_bind < mp11::mp_plus, mp11::mp_bind<mp11::mp_back, mp11::_1>, mp11::_2 > > >; static_assert(mp11::mp_at_c<first_bit_list, 0>::value == 0, "first bit must be 0"); public: using type = mp11::mp_transform < reference_type, mp11::mp_pop_back<first_bit_list>, RangeBitSizes >; }; using reference3_list = typename bit_range_reference_list < std::uint8_t, mp11::mp_list_c<int, 3> >::type; int main() { using r1_t = mp11::mp_at_c<reference3_list, 0>; using r2_t = bit_range_reference<std::uint8_t, 0, 3, true>; using r2c_t= bit_range_reference<std::uint8_t, 0, 3, true> const; //#if defined(__GNUC__) && (__GNUC__ == 4) // GCC 4.8 compiles, later versions of GCC fail to compile static_assert(std::is_same<r1_t, r2_t>::value, "GCC says r1_t is const-qualified"); //#else // GCC 4.9, 5, 6, 7, 8 versions compile, GCC 4.8 fail to compile static_assert(std::is_same<r1_t, r2c_t>::value, "GCC says r1_t is NOT const-qualified"); //#endif } ``` To summary, I expect this to yield true: std::is_same < mp11::mp_at_c<reference3_list, 0> bit_range_reference<std::uint8_t, 0, 3, true> const > I got this confirmed by all GCC versions but GCC 4.8. (clang and MSVC also seem to agree with the GCC >= 4.9) Is mp11::mp_transform loosing const-qualification or have I made a mistake somewhere? I'm using Boost.MP11 from Boost 1.70 and from current develop branch Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

Building Boost 1.70 with VS2019?
by Osman Zakir 19 Apr '19

19 Apr '19

Hi, everyone. How can I have Boost.Build use VS2019 when building Boost? I have a side-by-side installation of VS2019 on my computer, along with VS2017 also still being there. If this hasn't been tested yet, I'll wait until it has.

3 4

boost::xpressive use of before(...)
by Simon Giddings 18 Apr '19

18 Apr '19

Good morning, In our project I have the enviable task of transforming a large number of perl regex into boost::xpressive static code in c++. To ensure that the code I write, I have put together a simple test app where I create the sregex object and can then test that the result is that which is exected. I am stuck with the use of before(...) Here is my test - which fails std::string strInput = "&9-A02FEfoo"; sregex re; re = bos >> as_xpr("&9-A02FE") >> before("foo"); if(regex_match(strInput, sm, re)) { strResult = "matched : " + sm[0].str(); } According to the documentation (v1.67) this should work. What am I doing wrong here ? Best regards Simon

2 1

Need help resolving Boost error with Log Library: Candidate function not viable, expects an l-value for 1st argument
by Austin Tapp 15 Apr '19

15 Apr '19

Hello, I am trying to resolve this error: "5. Candidate function [with LoggerT = boost::log::v2s_mt_posix::sources::severity_logger_mt<boost::log::v2s_mt_posix::trivial::severity_level>] not viable: expects an l-value for 1st argument". This error results in the inability to use the function "make_record_pump", in my .cxx file, because "make_record_pump" is not recognized as a function within "record_ostream.hpp" due to the previous error. I am attempting to compile this project on Xcode 10.2, after building the project with the newest version of CMake. I have built boost (version 1.69.0) and installed the dynamic libraries with homebrew. Thank you, Austin Tapp

1 0

[gil] Boost.MPL replaced with Boost.MP11
by Mateusz Loskot 14 Apr '19

14 Apr '19

Hi, FYI, Boost.GIL switched from MPL and TypeTraits to MP11 (thank you Peter Dimov!) and C++11 <type_traits>: https://github.com/boostorg/gil/pull/274 This is a significant refactoring and as such it may have introduced bugs. GIL tests coverage had not been 100% and despite we've added numerous new tests, it's still far from complete. Any GIL users out there, if you notice any bugs, please let us know by opening new issue at GitHub or posting to to https://lists.boost.org/boost-gil/ Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[release] Boost 1.70.0
by Marshall Clow 12 Apr '19

12 Apr '19

Release 1.70.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains numerous enhancements and bug fixes for existing libraries. For details, including download links, see < http://www.boost.org/users/news/version_1.70.0> You can also download directly from: < https://dl.bintray.com/boostorg/release/1.70.0/source> SHA-256 sums: ae2bb1b35d1f238e72e3f819b42336f4bd27c9ed2092aab5d87818ccb0c9161a boost_1_70_0.7z 430ae8354789de4fd19ee52f3b1f739e1fba576f0aded0897c3c2bc00fb38778 boost_1_70_0.tar.bz2 882b48708d211a5f48e60b0124cf5863c1534cd544ecd0664bb534a4b5d506e9 boost_1_70_0.tar.gz 48f379b2e90dd1084429aae87d6bdbde9670139fa7569ee856c8c86dd366039d boost_1_70_0.zip To install this release on your system, see < http://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. Thanks, -- The Boost Release Team Vladimir Prus, Marshall Clow, Daniel James, Micheal Caisse

4 3

[release] Boost 1.70.0 Release Candidate 2 available
by Marshall Clow 11 Apr '19

11 Apr '19

The second release candidate for the 1.70.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.70.0/source/> Changes since rc1: * Boost.Config changes to work better with msvc-14.2 * Boost.Beast bug fixes * Boost.Move bug fix * Boost.Math non-ascii characters removed from header file The SHA256 checksums are as follows: 882b48708d211a5f48e60b0124cf5863c1534cd544ecd0664bb534a4b5d506e9 ./boost_1_70_0_rc2.tar.gz 430ae8354789de4fd19ee52f3b1f739e1fba576f0aded0897c3c2bc00fb38778 ./boost_1_70_0_rc2.tar.bz2 48f379b2e90dd1084429aae87d6bdbde9670139fa7569ee856c8c86dd366039d ./boost_1_70_0_rc2.zip ae2bb1b35d1f238e72e3f819b42336f4bd27c9ed2092aab5d87818ccb0c9161a ./boost_1_70_0_rc2.7z 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. -- The Boost Release Managers

3 5

[variant2] Review - Review period extended until April 15
by Michael Caisse 09 Apr '19

09 Apr '19

Hi all - The review period for Boost.Variant2 has bee extended to April 15. Thank you to those who have participated so far. There has been a fair amount of discussion about the merits of never valueless. A core design _feature_ of Variant2 is never valueless. You may have made different trade-offs. Understanding motives makes sense but in this review we are not trying to change this basic design choice. This paper by Peter discusses valueless variants some and may be useful reading: <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0308r0.html> If you haven't started your review yet, you have time! Reviews ranging from detailed discussions of inner workings to a user-perspective of the library and documentation are all helpful. I personally believe we need more user-based reviews in Boost. So, feeling sheepish about reviewing? Don't! Your review is important in the process. Here is one more motivation if you are on the fence ... Peter's code is a joy to read. The library is extremely clean and the code is accessible. There might be all kinds of things you learn from reading the source. Thank you again community for staying involved. We get great libraries when people ask questions, review, and provide input to everything from the docs to the design. Happy coding! michael -- Michael Caisse Ciere Consulting ciere.com

1 0

Re: [Boost-users] [boost] [release] Boost 1.70.0 Release Candidate 1 available
by Vinnie Falco 09 Apr '19

09 Apr '19

On Mon, Apr 8, 2019 at 3:51 PM Stefan Seefeld <stefan(a)seefeld.name> wrote: > At this point in time, I'd argue...fixes, to make sure... > But soft, what commit through yonder git log states? It is a bug, and 5e88637752ea0ecb49824904be3098656740298c is the fix! ... To merge, or not to merge? That is the question. Regards

1 0

[release] Boost 1.70.0 Release Candidate 1 available
by Marshall Clow 08 Apr '19

08 Apr '19

The release candidates for the 1.70.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.70.0/source/> The SHA256 checksums are as follows: 6e5cba1269225395bb5e78dda48441ccadaf745e42638180015e9e6257068336 ./boost_1_70_0_rc1.7z 35d8e1361e2063f70aa3a6ca0dd8af0877ceb75477ebbd2c726bb1d039658c7a ./boost_1_70_0_rc1.tar.bz2 ec8ddbbee2fd61e2f78a1dfe9a07ad83ca8f6a2f4c704d6f297d89c6afdc4f2c ./boost_1_70_0_rc1.tar.gz ee2c3b97ce10f85a31b6a105ad8edf1c20fb4b936c9a6e6008206059cb98ab1b ./boost_1_70_0_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. -- The Boost Release Managers

8 15

Newbie error trying to construct an offset_ptr in a managed shared memory segment.
by Bill Baker 03 Apr '19

03 Apr '19

1 0

cannot compile boost pmr small_vector snippet
by Pedro Pinto pedro.pinto＠bluetradesys.com 02 Apr '19

02 Apr '19

Hi there, I am trying to use the pmr version of the boost small_vector container. I expected the following to work: #include <boost/container/pmr/polymorphic_allocator.hpp>#include <boost/container/pmr/small_vector.hpp> boost::container::pmr::polymorphic_allocator<int> alloc; boost::container::pmr::small_vector<int,4> vec(alloc); But this does not compile with boost 65, gcc 7.3/clang 6.0. The compile error seems to suggest I should be using small_vector_allocator which is an internal class. The exact clang error is below. Am I missing something here? Thanks /usr/include/boost/container/small_vector.hpp:514:41: note: candidate constructor not viable: no known conversion from 'boost::container::pmr::polymorphic_allocator<int>' to 'const boost::container::small_vector<int, 4, boost::container::pmr::polymorphic_allocator<int> >::allocator_type' (aka 'const small_vector_allocator<boost::container::pmr::polymorphic_allocator<int> >') for 1st argument BOOST_CONTAINER_FORCEINLINE explicit small_vector(const allocator_type &a)

1 0

[variant2] Review of Variant2 started today : April 1 - April 10
by Michael Caisse 02 Apr '19

02 Apr '19

The Boost formal review of Peter Dimov's Variant2 library will take place April 1 - 10, 2019. Please consider participating in this review. The success of Boost is partially a result of the quality review process which is conducted by the community. You are part of the Boost community. I will be grateful to receive a review based on whatever level of effort or time you can devote. Variant2 is a never-valueless C++11/14/17 implementation of std::variant. >From the README: The class boost::variant2::variant<T...> is an almost conforming implementation of std::variant with the following differences: * A converting constructor from, e.g. variant<int, float> to variant<float, double, int> is provided as an extension; * The reverse operation, going from variant<float, double, int> to variant<int, float> is provided as the member function subset<U...>. (This operation can throw if the current state of the variant cannot be represented.) * variant<T...> is not trivial when all contained types are trivial. To avoid going into a valueless-by-exception state, this implementation falls back to using double storage unless * one of the alternatives is the type monostate, * one of the alternatives has a nonthrowing default constructor, or * all the contained types are nothrow move constructible. If the first two bullets don't hold, but the third does, the variant uses single storage, but emplace constructs a temporary and moves it into place if the construction of the object can throw. In case this is undesirable, one can force emplace into always constructing in- place by adding monostate as one of the alternatives. You can find the source code here: <https://github.com/pdimov/variant2> The master branch will be stable for the review: <https://github.com/pdimov/variant2/tree/master> Find the documentation here (also stable during the review): <https://pdimov.github.io/variant2/doc/html/variant2.html> Note: The repository contains an expected implementation also; however, that is not being considered in this review. Please provide in your review information you think is valuable to understand your choice to ACCEPT or REJECT including Variant2 as a Boost library. Please be explicit about your decision (ACCEPT or REJECT). Some other questions you might want to consider answering: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? More information about the Boost Formal Review Process can be found here: <http://www.boost.org/community/reviews.html> Thank you for your effort in the Boost community. Happy coding - michael -- Michael Caisse Ciere Consulting ciere.com

1 0