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

[review][fixed_string] FixedString review starts Nov 25
by Joaquin M López Muñoz 21 Nov '19

21 Nov '19

The Boost formal review of Krystian Stasiowski and Vinnie Falco's FixedString library will take place November 25 - December 4, 2019. This is an early call for you to consider participating in the review. Feedback and constructive criciticism from experts and not-so-experts alike is very much welcome. FixedString being a relatively small and straightforward library, you will find it very easy to familiarize yourself with it and contribute back to the community. FixedString provides a dynamically resizable string of characters with compile-time fixed capacity and contiguous embedded storage in which the characters are placed within the string object itself. Its API closely resembles that of std::string. GitHub repository: https://github.com/18/fixed_string Online docs: https://18.github.io/doc/fixed_string If you feel like reviewing FixedString you can start now prepping --though I'd ask you to refrain from submitting actual reviews till Nov 25. Read the docs, download/fork the code, read/run it, maybe try integrating it into some project of yours, ask questions to the authors, preferrably on Boost or Boost Users mailing lists. The FixedString initiative arose from a very lively discussion within the community: https://lists.boost.org/Archives/boost/2019/09/246943.php , so I sincerely hope this review will be a fruitful, crowded one. Don't let me down! Best regards, Joaquín M López Muñoz Review manager for candidate Boost.FixedString

1 0

[release] Boost 1.72.0 Beta 1
by Michael Caisse 21 Nov '19

21 Nov '19

Boost release 1.72.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.72.0.beta.1/source/> The SHA256 checksums are as follows: 5a6b5cbd27b8ca0c7741b715e022a3bf05aecbb1e73dc72dd82eef9622374bd5 boost_1_72_0_b1.7z 6c85a7aed198757f5e4be66a971ae90a25c4ce32703fecfb5bb19019bd80947c boost_1_72_0_b1.tar.bz2 be4a3fdaa84d5a8b25863651043308e02645f3fbf772b7623ee6462fb1dbad09 boost_1_72_0_b1.tar.gz 95181a5f3de0078b8fc031f63a4dc8be4d70b7d3d5cde3b266d2cd98bd4b61b0 boost_1_72_0_b1.zip For details of what's in the release, see <https://www.boost.org/users/history/version_1_72_0.html>. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

1 0

boost::errinfo_stacktrace?
by Nat Goodspeed 21 Nov '19

21 Nov '19

Since the arrival of Boost.Stacktrace, I've been expecting a conventional boost::errinfo_stacktrace helper to join the suite of other boost::errinfo_mumble helpers. Is there a PR open with that? -- NAT LINDEN | Senior Software Engineer | Real Life: Nat Goodspeed LINDEN LAB | Create Virtual Experiences <https://www.lindenlab.com>

4 5

[multi_index] Indices interface type for overload resolution
by Christophe B 20 Nov '19

20 Nov '19

Hi, I have currently template <typename Key, typename Value> std::vector<Key> keys(const std::map<Key, Value> &m) { ... } I'd like to write an overload that works also with the indices interface of multi_index_container. Suppose I have a multi_index_container with ordered unique indexes tagged "by_id" and "by_name". struct by_id {}; struct by_name {}; using BMI = multi_index::multi_index_container<Value, multi_index::indexed_by< multi_index::ordered_unique<by_id, multi_index::key<&Value::id>>, multi_index::ordered_unique<by_name, multi_index::key<&Value::name>> >>; BMI bmi; auto k = keys(bmi.get<by_name>()); Based on the documentation, I tried template< typename Tag,typename Value,typename IndexSpecifierList,typename Allocator > auto keys(const typename multi_index::index< multi_index::multi_index_container<Value,IndexSpecifierList,Allocator>,Tag>::type& m) { typedef decltype(c.key_extractor()(*c.begin())) key_type; // A better definition would be welcome std::vector<key_type> result; result.reserve(c.size()); for (const auto &elem : c) { result.push_back(c.key_extractor()(elem)); } return result; } But the overload resolution fails. What should be the interface of keys in order to support indices interface of multi_index_container? Thank you, Christophe B

3 2

bracket_and_solve_root "rising" option
by Saurabh T 07 Nov '19

07 Nov '19

Hi, I would like a way to bracket the root without having to compute or specify the "rising" flag to "bracket_and_solve_root". Is there a way to edit the bracketing implementation so the user need not specify that option? Thanks, saurabh

3 3

[preprocessor] increase tuple size
by pavel b 07 Nov '19

07 Nov '19

Hi, preprocessor/config/limits.hpp limits tuple size to 64 elements. Changing the BOOST_PP_LIMIT_TUPLE in this file seems not to have any effect. Is it possible to increase the maximal tuple size? Are there scripts to update dependent macros like BOOST_PP_TUPLE_ELEM_* in preprocessor/tuple/elem.hpp? Thanks in advance

3 7

boost::read_graphml
by scaliwagjones＠yahoo.com 07 Nov '19

07 Nov '19

I understand that compiling is no longer necessary to read graphml files.My program compiles but does not link. It worked before I upgraded boost_1_71_0. Program: #include <iostream> #include <boost/graph/graphml.hpp> #include <boost/graph/adjacency_list.hpp> using namespace std; using namespace boost; typedef adjacency_list < vecS, vecS, bidirectionalS > graph_t; graph_t g; dynamic_properties dpg; int main( ) { read_graphml(cin, g, dpg, 0); } Makefile: read_graphml_test: read_graphml_test.cpp g++ -c -I/usr/local/boost_1_71_0 read_graphml_test.cpp ############ g++ -I/usr/local/boost_1_71_0 -L/usr/local/boost_1_71_0/stage/lib read_graphml_test.o Error message: undefined reference to `boost::read_graphml(std::istream&, boost::mutate_graph&, unsigned long)' Thanx

1 0

[filesystem] Management of junction on Windows is broken and api is inconsistent
by Vince R. 06 Nov '19

06 Nov '19

Hello, I am bit disappointed to see that symlink and junctions are still not really properly handled on Windows with boost (and even with standard MS libs but that's another story.) First my environment: Windows 10, VS2019 16.3.7, boost 1.71 (static, x64). I would like to write a small c++ utility that does not use os dependent code to handle files so filesystem seems a good candidate. Here is what I am doing on Windows: cd "C:\Users\Vincent\AppData\Roaming\Apple Computer\MobileSync" mklink /j Backup E:\Backup So basically I am creating inside C:\..\MobileSync a junction folder that points to my second harddisk E:\Backup Then I am checking that Windows recognize it by entering dir command: 01/11/2019 23:48 <DIR> . 01/11/2019 23:48 <DIR> .. 01/11/2019 23:29 <JUNCTION> Backup [E:\Backup] 0 fichier(s) 0 octets 3 Rép(s) 59 393 630 208 octets libres As you can see I have a junction targeting E:\Backup, so now let's see what happens with boost: fs::path p(_T("C:\\Users\\Vincent\\AppData\\Roaming\\Apple Computer\\MobileSync\\Backup")); sys::error_code ec; if (fs::is_symlink(p)) { fs::path pathTarget = fs::read_symlink(p, ec); } When I display the content of pathTarget I have: L"\\Backup" ie Backup if I decode it into human string I might not understand anything about junction but is it not supposed to return E:\Backup ?? When I look at source code I can see the following lines: /********************** boost_1_71_0\libs\filesystem\src\operations.cpp **************************************/ symlink_path.assign( static_cast<wchar_t*>(info.rdb.SymbolicLinkReparseBuffer.PathBuffer) + info.rdb.SymbolicLinkReparseBuffer.PrintNameOffset/sizeof(wchar_t), static_cast<wchar_t*>(info.rdb.SymbolicLinkReparseBuffer.PathBuffer) + info.rdb.SymbolicLinkReparseBuffer.PrintNameOffset/sizeof(wchar_t) + info.rdb.SymbolicLinkReparseBuffer.PrintNameLength/sizeof(wchar_t)); This is wrong since we need to distinguish between a symlink and a junction folder so here is my contribution : --- a/src/operations.cpp +++ b/src/operations.cpp @@ -201,6 +201,12 @@ typedef struct _REPARSE_DATA_BUFFER { # ifndef IO_REPARSE_TAG_SYMLINK # define IO_REPARSE_TAG_SYMLINK (0xA000000CL) # endif +# ifndef IO_REPARSE_TAG_MOUNT_POINT +# define IO_REPARSE_TAG_MOUNT_POINT (0xA0000003L) +# endif +# ifndef IO_REPARSE_TAG_DEDUP +# define IO_REPARSE_TAG_DEDUP (0x80000013L) +# endif inline std::wstring wgetenv(const wchar_t* name) { @@ -1661,12 +1667,24 @@ namespace detail if (!error(::DeviceIoControl(h.handle, FSCTL_GET_REPARSE_POINT, 0, 0, info.buf, sizeof(info), &sz, 0) == 0 ? BOOST_ERRNO : 0, p, ec, "boost::filesystem::read_symlink" )) + if (info.rdb.ReparseTag == IO_REPARSE_TAG_SYMLINK) + { symlink_path.assign( static_cast<wchar_t*>(info.rdb.SymbolicLinkReparseBuffer.PathBuffer) + info.rdb.SymbolicLinkReparseBuffer.PrintNameOffset/sizeof(wchar_t), static_cast<wchar_t*>(info.rdb.SymbolicLinkReparseBuffer.PathBuffer) + info.rdb.SymbolicLinkReparseBuffer.PrintNameOffset/sizeof(wchar_t) + info.rdb.SymbolicLinkReparseBuffer.PrintNameLength/sizeof(wchar_t)); + } + else if (info.rdb.ReparseTag == IO_REPARSE_TAG_MOUNT_POINT) + { + symlink_path.assign( + static_cast<wchar_t*>(info.rdb.MountPointReparseBuffer.PathBuffer) + + info.rdb.MountPointReparseBuffer.PrintNameOffset / sizeof(wchar_t), + static_cast<wchar_t*>(info.rdb.MountPointReparseBuffer.PathBuffer) + + info.rdb.MountPointReparseBuffer.PrintNameOffset / sizeof(wchar_t) + + info.rdb.MountPointReparseBuffer.PrintNameLength / sizeof(wchar_t)); + } # endif return symlink_path; } I will add more suggestions in a next message because there is no consistency between boost and MSVC approach. I don't know the last c++ specifications but it shouldn't be difficult to have a simple approach;

1 0

How multiprecision optimizes allocation?
by Andy 05 Nov '19

05 Nov '19

I have tested boost::mulitprecision::cpp_int and have tested simplest algorithm for int multiplication My test method is several times slower than boost multiplication because I resized product vector to size fist + size second. This allocation take most time, if I use static array on stack, it will be fast for small numbers. What is the riddle of fast comnputing z = x*y in loop for quite small x and y in Boost cpp_int?

2 3

Comparing boost::multiprecision cpp_int and mpz_int
by Andy 05 Nov '19

05 Nov '19

cpp_int is more convenient but mpz_int is faster especially for long numbers? What say benchmarks? For mpz_int I must install GMP on Linux or build MPIR on WIndows (build lib_mpir_core2) ? I want make sample benchmark test but I can't convert cpp_it to mpz_int nor iport bits, whereas for cpp_int I can import_bits(x, xBytes.begin(), xBytes.end()) where vector<uint8_t> xBytes; Question: is possible import byte array to mpz_int?

2 1