April 2018 - Boost - lists.boost.org

[GSoC] My proposal with Boost C++ was accepted!!
by Laouen Belloli 27 Apr '18

27 Apr '18

Hi, Boost community, I was notified some days ago that my proposal for the Boost.Real project was accepted in the Google Summer of Code 2018 program. I'm currently in contact with my mentor (Damian Vicino) talking about how to start the project and how to properly work to get a clean and performant code. Any suggestion about common working methodologies in boost projects are welcome, and if there is a tutorial on the boost programming style please let me know so I can achieve a cleaner coding style that fits better with the rest of the library projects and facilitate the review process. Regarding where to store the project: I have received an invitation to join the BoostGSoC18 GitHub organization from David Bellot. Is this a good place where to create the Boost.Real project? I suppose that the organization was created for this purpose, but because I only got the invitation I don't want to create my project within the organization without asking first. Best, -- Laouen Mayal Louan Belloli. LIAA - DC - FCEyN - UBA. C.A.B.A. - Buenos Aires - Argentina. https://liaa.dc.uba.ar +54 9 11 38675694

2 1

[config] Macro for "using" type alias defects
by Raffi Enficiaud 27 Apr '18

27 Apr '18

Hi all, I was wondering if there is any macro in Boost.Config for advertising the defect of the "using" support from the compiler. I was reported this: https://github.com/boostorg/test/pull/140 and at the time I wrote the thing, I thought that those guards would have been enough: https://github.com/boostorg/test/blob/35c9acf5bd38d625ebd45cf940c5b9a19aa22… (auto, tuple and variadic template sounds to me more difficult to support than "using" template alias). Would it make sense to have BOOST_NO_CXX11_TYPE_ALIAS? Thanks, Raffi

3 7

Boost issue or no?
by Joshua Alexander 26 Apr '18

26 Apr '18

Hi all, I am trying to build pCloudCC and not sure if this is a Boost issue or a pCloud issue: # make [ 10%] Building C object CMakeFiles/sqlite3.dir/lib/sqlite/sqlite3.c.o [ 20%] *Linking C static library libsqlite3.a* [ 20%] Built target sqlite3 [ 30%] Building CXX object CMakeFiles/pcloudcc_lib.dir/pclsync_lib_c.cpp.o [ 40%] Building CXX object CMakeFiles/pcloudcc_lib.dir/pclsync_lib.cpp.o In file included from */root/build/console-client-master/pCloudCC/pclsync_lib.cpp:30:0*: */root/build/console-client-master/pCloudCC/lib/pclsync/pcompat.h:95:0:* *warning:*"_GNU_SOURCE" redefined [enabled by default] #define _GNU_SOURCE * ^* *<command-line>:0:0:* *note: *this is the location of the previous definition In file included from */usr/local/include/boost/smart_ptr/detail/local_sp_deleter.hpp:20:0*, from */usr/local/include/boost/smart_ptr/shared_ptr.hpp:1158*, from */usr/local/include/boost/shared_ptr.hpp:17*, from */root/build/console-client-master/pCloudCC/pclsync_lib.cpp:45*: */usr/local/include/boost/smart_ptr/detail/local_counted_base.hpp:* In member function ‘*void boost::detail::local_counted_base::add_ref()*’: */usr/local/include/boost/smart_ptr/detail/local_counted_base.hpp:67:49:* *error: **__builtin_assume*’ was not declared in this scope __builtin_assume( local_use_count_ >= 1 ); * ^* In file included from */usr/local/include/boost/smart_ptr/detail/sp_counted_impl.hpp:29:0*, from */usr/local/include/boost/smart_ptr/detail/shared_count.hpp:30*, from */usr/local/include/boost/smart_ptr/shared_ptr.hpp:28* , from */usr/local/include/boost/shared_ptr.hpp:17*, from */root/build/console-client-master/pCloudCC/pclsync_lib.cpp:45*: /usr/local/include/boost/core/addressof.hpp: In instantiation of ‘*T* boost::addressof(T&) [with T = int (*)(_IO_FILE*)]*’: */usr/local/include/boost/smart_ptr/detail/sp_counted_impl.hpp:182:98:* required from ‘*void* boost::detail::sp_counted_impl_pd<P, D>::get_local_deleter(const sp_typeinfo&) [with P = _IO_FILE*; D = int (*)(_IO_FILE*); boost::detail::sp_typeinfo = std::type_info]*’ */root/build/console-client-master/pCloudCC/pclsync_lib.cpp:304:1:* required from here */usr/local/include/boost/core/addressof.hpp:40:33:* *error: *‘ *__builtin_addressof*’ was not declared in this scope return __builtin_addressof(o); * ^* make[2]: *** [CMakeFiles/pcloudcc_lib.dir/pclsync_lib.cpp.o] Error 1 make[1]: *** [CMakeFiles/pcloudcc_lib.dir/all] Error 2 make: *** [all] Error 2

2 4

[range] master broken in latest MSVC
by Vinnie Falco 26 Apr '18

26 Apr '18

I'm using the latest release of Visual Studio and I get these errors from the master superproject: 8>c:\users\vinnie\src\boost\boost\range\concepts.hpp(257): error C3646: 'n': unknown override specifier 8>c:\users\vinnie\src\boost\boost\range\concepts.hpp(264): note: see reference to class template instantiation 'boost::range_detail::RandomAccessIteratorConcept<Iterator>' being compiled 8>c:\users\vinnie\src\boost\boost\range\concepts.hpp(257): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int This issue exactly describes the problem: <https://github.com/boostorg/range/issues/68> Thanks

2 1

[lexical_cast] calling virtual function in constructor of `boost::detail::basic_pointerbuf`
by Andrzej Krzemienski 25 Apr '18

25 Apr '18

Hi everyone, Following the recommendation, I am posting a note about the filed issue in lexical_cast: https://svn.boost.org/trac10/ticket/13540#ticket clang-tidy reports (while checking the code that uses boost::lexical_cast) a virtual function is called in the default constructor of class template boost::detail::basic_pointerbuf. (Function setbuf() is declared virtual in base class.) This might be an indication of a bug. If not, I would recommend using a different construct that avoids confusion, for instance declaring the function override final in newer versions of C++, or providing another function with different name but with the same semantics as the overriding setbuf(). Here's the link to the offending call: https://github.com/boostorg/lexical_cast/blob/develop/include/boost/detail/… Regards, &rzej;

1 0

Fornux C++ Superset
by Phil Bouchard 25 Apr '18

25 Apr '18

Greetings, Because there was a conflict of interests in the past then I feel obliged to give an update regarding the status of the "Fornux C++ Superset" (formerly "Fornux C Leak Detector"). This way corporations will not claim ownership of the idea. - Fornux C++ Superset harnesses the power of Clang. - It now supports, as you have guessed, C++98 syntax. - It's deterministic so it will not slow down your application randomly like with Java. - You can see attached examples memory leaks in C & C++ with cyclic references which are correctly handled and the memory usage never increases. Like I mentioned previously, I am working hard on a free version I will be able to share in a month or two. Regards, Phil Bouchard www.fornux.com

2 2

[interprocess] Enhancment for Boost.Interprocess on Windows
by Aliaksandr Zaitsau 24 Apr '18

24 Apr '18

Hello, My colleague at work suggests an enchancement for Boost.Interprocess for detecting unique boot on Windows. Currently in Boost.Interprocess we have 3 implementations: 1. Using COM. It is marked as incorrect in case of hibernation. 2. Current default implementation using system events log is incorrect since lots of computers will not have expected event in system event log. 3. There is some new for me implementation using reading Windows registry. It is disabled by default. Question 1 What Windows versions are expected to be supported by current library version? What about Windows XP? Earlier Windows? Question 2 What is the status of third implementation via registry? Question 3 It seems strange for him third implementation needs 2 registry values for creating unique id. First of them looks enough for this purpose. And another one may be not present on some Windows. Who may he speak to get technical details why this implementation looks like this? He has an idea how to implement unique boot id better than first and second implementations. He tried to email Ion Gaztanaga directly, but without any responce. Is it good idea to create PR on GitHub before getting any details from Ion? Best regards, Alexander Zaitsev

2 1

UUID broken with Boost 1.67 and VS2015?
by rleigh＠codelibre.net 23 Apr '18

23 Apr '18

In a source file including: #include <boost/uuid/uuid.hpp> #include <boost/uuid/uuid_io.hpp> #include <boost/uuid/uuid_generators.hpp> and then calling boost::uuids::to_string(boost::uuids::random_generator()()) I'm getting: [15/26] Linking CXX executable test\ome-files\ometiffwriter.exe FAILED: test/ome-files/ometiffwriter.exe cmd.exe /C "cd . && "C:\Program Files\CMake\bin\cmake.exe" -E vs_link_exe --intdir=test\ome-files\CMakeFiles\ometiffwriter.dir --manifests -- C:\PROGRA~2\MICROS~1.0\VC\bin\amd64\link.exe /nologo test\ome-files\CMakeFiles\ometiffwriter.dir\ometiffwriter.cpp.obj test\ome-files\CMakeFiles\ometiffwriter.dir\tiffsamples.cpp.obj /out:test\ome-files\ometiffwriter.exe /implib:test\ome-files\ometiffwriter.lib /pdb:test\ome-files\ometiffwriter.pdb /version:0.0 /machine:x64 /debug /INCREMENTAL /subsystem:console lib\ome\files\ome-filesd.lib lib\ome\test\ome-testd.lib C:\build\b\stage\lib\ome-xmld.lib C:\build\b\stage\lib\boost_random-vc140-mt-gd-x64-1_67.lib C:\build\b\stage\lib\tiffd.lib C:\build\b\stage\lib\ome-commond.lib C:\build\b\stage\lib\boost_iostreams-vc140-mt-gd-x64-1_67.lib C:\build\b\stage\lib\boost_log-vc140-mt-gd-x64-1_67.lib C:\build\b\stage\lib\boost_filesystem-vc140-mt-gd-x64-1_67.lib C:\build\b\stage\lib\boost_regex-vc140-mt-gd-x64-1_67.lib C:\build\b\stage\lib\boost_log_setup-vc140-mt-gd-x64-1_67.lib C:\build\b\stage\lib\boost_thread-vc140-mt-gd-x64-1_67.lib C:\build\b\stage\lib\boost_date_time-vc140-mt-gd-x64-1_67.lib C:\build\b\stage\lib\boost_chrono-vc140-mt-gd-x64-1_67.lib C:\build\b\stage\lib\boost_system-vc140-mt-gd-x64-1_67.lib C:\build\b\stage\lib\boost_atomic-vc140-mt-gd-x64-1_67.lib C:\build\b\stage\lib\Xalan-C_1D.lib C:\build\b\stage\lib\xerces-c_3D.lib C:\build\b\tools\lib\gtest.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib && cd ." LINK Pass 1: command "C:\PROGRA~2\MICROS~1.0\VC\bin\amd64\link.exe /nologo test\ome-files\CMakeFiles\ometiffwriter.dir\ometiffwriter.cpp.obj test\ome-files\CMakeFiles\ometiffwriter.dir\tiffsamples.cpp.obj /out:test\ome-files\ometiffwriter.exe /implib:test\ome-files\ometiffwriter.lib /pdb:test\ome-files\ometiffwriter.pdb /version:0.0 /machine:x64 /debug /INCREMENTAL /subsystem:console lib\ome\files\ome-filesd.lib lib\ome\test\ome-testd.lib C:\build\b\stage\lib\ome-xmld.lib C:\build\b\stage\lib\boost_random-vc140-mt-gd-x64-1_67.lib C:\build\b\stage\lib\tiffd.lib C:\build\b\stage\lib\ome-commond.lib C:\build\b\stage\lib\boost_iostreams-vc140-mt-gd-x64-1_67.lib C:\build\b\stage\lib\boost_log-vc140-mt-gd-x64-1_67.lib C:\build\b\stage\lib\boost_filesystem-vc140-mt-gd-x64-1_67.lib C:\build\b\stage\lib\boost_regex-vc140-mt-gd-x64-1_67.lib C:\build\b\stage\lib\boost_log_setup-vc140-mt-gd-x64-1_67.lib C:\build\b\stage\lib\boost_thread-vc140-mt-gd-x64-1_67.lib C:\build\b\stage\lib\boost_date_time-vc140-mt-gd-x64-1_67.lib C:\build\b\stage\lib\boost_chrono-vc140-mt-gd-x64-1_67.lib C:\build\b\stage\lib\boost_system-vc140-mt-gd-x64-1_67.lib C:\build\b\stage\lib\boost_atomic-vc140-mt-gd-x64-1_67.lib C:\build\b\stage\lib\Xalan-C_1D.lib C:\build\b\stage\lib\xerces-c_3D.lib C:\build\b\tools\lib\gtest.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST /MANIFESTFILE:test\ome-files\CMakeFiles\ometiffwriter.dir/intermediate.manifest test\ome-files\CMakeFiles\ometiffwriter.dir/manifest.res" failed (exit code 1120) with the following output: Creating library test\ome-files\ometiffwriter.lib and object test\ome-files\ometiffwriter.exp ome-filesd.lib(OMETIFFWriter.cpp.obj) : error LNK2019: unresolved external symbol BCryptCloseAlgorithmProvider referenced in function "public: __cdecl boost::uuids::detail::random_provider_base::~random_provider_base(void)" (??1random_provider_base@detail@uuids@boost@@QEAA@XZ) ome-filesd.lib(OMETIFFWriter.cpp.obj) : error LNK2019: unresolved external symbol BCryptGenRandom referenced in function "public: void __cdecl boost::uuids::detail::random_provider_base::get_random_bytes(void *,unsigned __int64)" (?get_random_bytes@random_provider_base@detail@uuids@boost@@QEAAXPEAX_K@Z) ome-filesd.lib(OMETIFFWriter.cpp.obj) : error LNK2019: unresolved external symbol BCryptOpenAlgorithmProvider referenced in function "public: __cdecl boost::uuids::detail::random_provider_base::random_provider_base(void)" (??0random_provider_base@detail@uuids@boost@@QEAA@XZ) test\ome-files\ometiffwriter.exe : fatal error LNK1120: 3 unresolved externals Looking at boost/winapi/bcrypt.hpp from the 1.67.0 source tar.bz2, I see these symbols prototyped, but not defined anywhere. Is this header broken, missing the implementation? Thanks, Roger

4 4

Seeking help to build GitHub forks on AppVeyor and Travis
by Cromwell Enage 22 Apr '18

22 Apr '18

Hi, all! 1. Is this the right mailing list to seek help for building forks of Boost library modules on GitHub? If not, which mailing list should I bring the next questions to? 2. On my Boost.Parameter fork, one of the AppVeyor jobs gets cut off after 1 hour. How do I split the job into several jobs, one for each compiler or smaller set of compilers? 3. The Boost.MultiArray project on GitHub doesn't have AppVeyor or Travis configuration files, so I created a couple for my fork based on the ones that exist in Boost.Parameter. The AppVeyor jobs error out because they don't recognize the compile-fail rule when running the Jamfile script. Any clues as to what I'm missing? 4. On my Boost.MultiArray fork, one of the Travis jobs builds fine, but the other fails because <boost/array.hpp> is not found. Has anyone else run into this issue? If so, what was your workaround? My GitHub account is GitHub.com/CromwellEnage, in case anyone wants to peruse. Thanks in advance! Cromwell D. Enage

2 2

[graph][graph_parallel][disjoint_sets] Of dependencies and "pending" libraries.
by Rene Rivera 21 Apr '18

21 Apr '18

In the process of creating Conan packages I ran into the rather strange "disjoint_sets" library. It's a library that has been "pending" for 18 years, AFAICT. I don't know what a pending status means for this. But for creating modular packages it means it's a giant PITA to deal with the the interdependencies of "disjoint_sets", "graph", and "graph_parallel". What I want to know is: 1. What is this hidden "disjoint_sets" library/module that only has two headers? 2. Why isn't "disjoint_sets" in the "graph" library tree, especially given that it's not an official library (AFAICT)? 3. Why is "graph_parallel" not in the "graph" library also? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

3 4