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

filesystem::path crash on Windows when dealing with umlauts ( üëï )
by Gonzalo Garramuño 09 May '19

09 May '19

I am getting a crash on Windows when passing a path that contains umlauts (like sampëüö ) to the path constructor. I tried boost 1.69 and boost 1.60. Here's the code I am using: namespace fs = boost::filesystem; const char* tmp = setlocale(LC_ALL, N_("")); // Create and install global locale std::locale::global(boost::locale::generator().generate( N_("") )); // Make boost.filesystem use it fs::path::imbue(std::locale()); if ( !tmp ) tmp = setlocale( LC_ALL, NULL ); std::string program = argv[0]; fs::path file = fs::path( program ); // CRASH -- Gonzalo Garramuño

3 2

A property_tree like structure where key is also value?
by Jeanette C. 05 May '19

05 May '19

Hey hey, I need a hirarchical data representation in my program, which is well modelled by boost.property_tree, but my keys will also be my values. The tree will have a fixed depth, all keys/values are std::string and I expect maybe a few hundred leaves and maybe a hundred or so nodes in between. Is it worth looking for a different structure at all, considering that the program is designed for desktop systems? If so: is there another Boost library that would serve me better? Best wishes and thanks for any tips, 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'm not that innocent... <3 (Britney Spears)

1 0

[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