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

Re: [Boost-users] [boost] [release] Boost 1.68.0 Beta 1 -> warnings in filesystem, locale, thread, stacktrace, container
by Frédéric 30 Jul '18

30 Jul '18

1 0

Boost Spirit X3: populating different objects
by Matthieu Brucher 29 Jul '18

29 Jul '18

Hi all, I want to design a parser that can populate two maps while parsing. They have a slightly different values (key is a string in both cases), but I didn't see an example where this was done. Hence I'm not even sure this is possible? Would be easier, otherwise I need to add another check to see what kind of value is populated before I insert it inside my maps? Cheers, Matthieu -- Quantitative analyst, Ph.D. Blog: http://blog.audio-tk.com/ LinkedIn: http://www.linkedin.com/in/matthieubrucher

1 0

Boost Spirit X3 and spaces
by Matthieu Brucher 29 Jul '18

29 Jul '18

Hi, What is the best strategy to handle spaces with X3? The files I want to parse have sometimes spaces or tabs for separators, but I also need to scan number that have an attached suffix (so x3::double_ >> *x3::char_). If now I want to parse groups of strings, starting with a rule like const auto pin = x3::rule<class pin, std::string>() = x3::alpha >> *x3::char_; what is the best to create a vector of these? *pin or pin % ' ' and will the latter also handle tabs by default? Cheers, Matthieu -- Quantitative analyst, Ph.D. Blog: http://blog.audio-tk.com/ LinkedIn: http://www.linkedin.com/in/matthieubrucher

1 0

storing functions obtained with boost.dll as class fields
by Sean Farrow 29 Jul '18

29 Jul '18

Hi, I'm in the process of converting a project being compiled with msvc 2017 to use boost.dll. I've got a shared library loading and need to obtain and store a function in a class-level field. The function has the following typedef: typedef error_status_t (WINAPI *nvdaControllerTestIfRunningFunc)(void); I think my main issue is what shared_libary.Get<t> returns. Any help appreciated. Kind regards Sean.

1 0

Re: [Boost-users] [release] Boost 1.68.0 Beta 1 -> warnings in filesystem, locale, thread, stacktrace, container
by Frédéric 29 Jul '18

29 Jul '18

Hi, I have tested 1.68.0 on linux x86_64 with the following compilers: - g++ 8.2.0, - clang++ 5.0.2, - mingw-w64 + g++ 8.2.0 cross compiling to windows 32 bits, - mingw-w64 + g++ 8.2.0 cross compiling to windows 64 bits, - clang++ 5.0.2 cross compiliing to OSX 10.9 32 bits, - clang++ 5.0.2 cross compiliing to OSX 10.9 64 bits. I did not find any major issue. Just those warnings while building the libraries: * filesystem (g++ 8.2.0 and clang++ 5.0.2 on linux x86_64): libs/filesystem/src/operations.cpp: Dans la fonction « int {anonymous}::readdir_r_simulator(DIR*, dirent*, dirent**) »: libs/filesystem/src/operations.cpp:2126:18: warning: « int readdir_r(DIR*, dirent*, dirent**) » est obsolète [-Wdeprecated-declarations] { return ::readdir_r(dirp, entry, result); } ^~~~~~~~~ In file included from /usr/include/features.h:423, from /softs/gcc-8.2.0/include/c++/8.2.0/x86_64-pc-linux-gnu/bits/os_defines.h:39, from /softs/gcc-8.2.0/include/c++/8.2.0/x86_64-pc-linux-gnu/bits/c++config.h:508, from /softs/gcc-8.2.0/include/c++/8.2.0/cstddef:49, from ./boost/config/compiler/gcc.hpp:165, from ./boost/config.hpp:39, from ./boost/filesystem/operations.hpp:18, from libs/filesystem/src/operations.cpp:68: /usr/include/dirent.h:189:12: note: déclaré ici extern int __REDIRECT (readdir_r, ^~~~~~~~~~ * locale (many more than that one about deprecated std::auto_ptr): I wonder when auto_ptr will be removed but it would be nice to change it to unique_ptr. In file included from libs/locale/src/util/default_locale.cpp:10: ./boost/locale/util.hpp:180:28: warning: « template<class> class std::auto_ptr » est obsolète [-Wdeprecated-declarations] BOOST_LOCALE_DECL std::auto_ptr<base_converter> create_utf8_converter(); ^~~~~~~~ In file included from /softs/gcc-8.2.0/include/c++/8.2.0/bits/locale_conv.h:41, from /softs/gcc-8.2.0/include/c++/8.2.0/locale:43, from ./boost/locale/util.hpp:10, from libs/locale/src/util/default_locale.cpp:10: /softs/gcc-8.2.0/include/c++/8.2.0/bits/unique_ptr.h:53:28: note: déclaré ici template<typename> class auto_ptr; ^~~~~~~~ * thead with mingw w64 cross compiling to windows 32 bits on linux x86_64 with g++ 8.2.0: I guess this warning is due to the fact that time_t is 32 bits on windows 32 bits so this looks dangerous to me. libs/thread/src/win32/thread_primitives.cpp: Dans la fonction « boost::detail::win32::ticks_type boost::detail::win32::{anonymous}::get_tick_count_init() »: libs/thread/src/win32/thread_primitives.cpp:97:120: warning: transtypage entre types de fonctions incompatibles de « boost::winapi::FARPROC_ » {aka « int (__attribute__((stdcall)) *)() »} vers « boost::detail::win32::detail::gettickcount64_t » {aka « long long unsigned int (__attribute__((stdcall)) *)() »} [-Wcast-function-type] (boost::detail::win32::detail::gettickcount64_t)boost::winapi::get_proc_address(hKernel32, "GetTickCount64"); * stacktrace (windows 32 and 64 bits): In file included from ./boost/winapi/file_management.hpp:17, from ./boost/stacktrace/detail/safe_dump_win.ipp:20, from ./boost/stacktrace/safe_dump_to.hpp:210, from ./boost/stacktrace/frame.hpp:20, from ./boost/stacktrace/detail/frame_unwind.ipp:15, from libs/stacktrace/build/../src/basic.cpp:14: ./boost/winapi/overlapped.hpp:38:9: warning: le C++ ISO interdit les structures anonymes [-Wpedantic] }; ^ * iostreams (windows 64 bits): libs/iostreams/src/mapped_file.cpp: Dans la fonction membre « void boost::iostreams::detail::mapped_file_impl::try_map_file(boost::iostreams::detail::mapped_file_impl::param_type) »: libs/iostreams/src/mapped_file.cpp:324:29: warning: comparaison d'expressions entières de types signés différents: « boost::iostreams::stream_offset » {aka « long long int »} et « boost::iostreams::mapped_file_source::size_type » {aka « long long unsigned int »} [-Wsign-compare] (SIZE_T) (size_ != max_length ? size_ : 0), ~~~~~~^~~~~~~~~~~~~ gcc.compile.c++ bin.v2/libs/iostreams/build/gcc-8.2.0/debug/link-static/target-os-windows/threading-multi/gzip.o * container (OSX 32 and 64 bits, clang 5.0.2): many locations with this warning: In file included from libs/container/src/alloc_lib.c:24: In file included from libs/container/src/dlmalloc_ext_2_8_6.c:36: libs/container/src/dlmalloc_2_8_6.c:4085:27: warning: 'sbrk' is deprecated [-Wdeprecated-declarations] char* base = (char*)CALL_MORECORE(0); ^ libs/container/src/dlmalloc_2_8_6.c:1714:37: note: expanded from macro 'CALL_MORECORE' #define CALL_MORECORE(S) MORECORE_DEFAULT(S) ^ libs/container/src/dlmalloc_2_8_6.c:666:26: note: expanded from macro 'MORECORE_DEFAULT' #define MORECORE_DEFAULT sbrk ^ /softs/osxcross-10.9-5.0.2/bin/../SDK/MacOSX10.9.sdk/usr/include/unistd.h:580:1: note: 'sbrk' has been explicitly marked deprecated here __deprecated ^ /softs/osxcross-10.9-5.0.2/bin/../SDK/MacOSX10.9.sdk/usr/include/sys/cdefs.h:156:37: note: expanded from macro '__deprecated' #define __deprecated __attribute__((deprecated)) ^

1 0

Re: [Boost-users] building boost 1.67/1.68b1 on osx with emscripten 1.38
by danielle amethyst brake 27 Jul '18

27 Jul '18

> > > > > "how do I set the default architecture when building boost?" > > > > address-model=64 architecture=x86 > > > Indeed, using these two commands as ./b2 address-model=64 architecture=x86 changes both of those properties as expected. however, if I use them in conjunction with *toolset=emscripten*, the problem I originally asked about persists: ./b2 toolset=emscripten address-model=64 architecture=x86 Performing configuration checks - default address-model : 32-bit - default architecture : none Building the Boost C++ Libraries. - symlinks supported : yes error: No best alternative for libs/context/build/asm_sources next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>elf <threading>multi <toolset>gcc ... [more similar alternatives omitted for brevity --dab] - C++11 mutex : no - lockfree boost::atomic_flag : yes - Boost.Config Feature Check: cxx11_hdr_tuple : no - Boost.Config Feature Check: cxx11_lambdas : no - Boost.Config Feature Check: cxx11_noexcept : no - Boost.Config Feature Check: cxx11_nullptr : no - Boost.Config Feature Check: cxx11_rvalue_references : no - Boost.Config Feature Check: cxx11_template_aliases : no - Boost.Config Feature Check: cxx11_thread_local : no - Boost.Config Feature Check: cxx11_variadic_templates : no - Boost.Config Feature Check: cxx11_auto_declarations : no - Boost.Config Feature Check: cxx11_constexpr : no - Boost.Config Feature Check: cxx11_defaulted_functions : no - Boost.Config Feature Check: cxx11_final : no - Boost.Config Feature Check: cxx11_hdr_mutex : no *Error: ambiguity found when searching for best transformation* *Trying to produce type 'SEARCHED_LIB' from: * *Generators that succeeded:* * - searched-lib-generator* * - emscripten.searched-lib-generator* *First generator produced: * * - { %.no-action-icudata.SEARCHED_LIB }* *Second generator produced: * * - { %.no-action-icudata.SEARCHED_LIB }* to renew focus, the problem I am trying to solve is the last part there, ambiguity when searching for best transformation. it goes away if i disable icu, but it just yields another similar error. it was suggested that I need to provide the default architecture to solve the problem, but the way suggested to do that so far have not worked. your help is appreciated! Danielle Brake

4 4

Re: [Boost-users] Boost-users Digest, Vol 4962, Issue 4
by danielle amethyst brake 27 Jul '18

27 Jul '18

On Wed, Jul 25, 2018 at 2:38 PM <boost-users-request(a)lists.boost.org> wrote: > Send Boost-users mailing list submissions to > boost-users(a)lists.boost.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.boost.org/mailman/listinfo.cgi/boost-users > or, via email, send a message with subject or body 'help' to > boost-users-request(a)lists.boost.org > > You can reach the person managing the list at > boost-users-owner(a)lists.boost.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Boost-users digest..." > > > Today's Topics: > > 1. Re: building boost 1.67/1.68b1 on osx with emscripten 1.38 > (Oliver Kowalke) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 25 Jul 2018 20:37:18 +0200 > From: Oliver Kowalke <oliver.kowalke(a)gmail.com> > To: boost-users <boost-users(a)lists.boost.org> > Subject: Re: [Boost-users] building boost 1.67/1.68b1 on osx with > emscripten 1.38 > Message-ID: > < > CA+wfc194-XJZ9dspcJBA844+x1EPphQfRnUr_E8WBjOAyCnUCg(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > default architecture : none > > you have time set the architecture > > Thanks for the advice. i just spent the last few hours flailing wildly trying to do this. Please accommodate my noob-ness here, as I have never had to set the default architecture before when building Boost. I tried setting it at the call to `b2`, with `b2 architecture=x86 ...`, and it did not effect this problem; the default architecture persists at `none` to my dismay. I have tried editing a user-config.jam file, but I just don't grok what I need to do here. at the risk of sounding like "can you do it for me?", I would like to ask "how do I set the default architecture when building boost?" danielle > danielle amethyst brake via Boost-users <boost-users(a)lists.boost.org> > schrieb am Mi., 25. Juli 2018, 20:11: > > > Hey Boost, > > I am trying to build Boost, ideally in its entirety, with emscripten. I > > am using emscripten 1.38.8, and either Boost 1.67 or the 1.68.b1, and am > on > > OSX 10.13. Both Boost versions fail. > > > >

2 1

State of latest RC
by Michael Powell 26 Jul '18

26 Jul '18

Hello, What is the state of the latest RC? I saw some reports that the build was a non-starter, then a patched RC, then no further reports after that? Or have I missed something? Thanks! Cheer, Michael W Powell

1 0

[GIL] read/write jpeg image from/to a buffer, not a file
by Frédéric 26 Jul '18

26 Jul '18

Hi, Is it possible to read/write an image as JPEG from/into a memory buffer instead of a file? I found that reference which looks promising: https://stackoverflow.com/questions/16259659/read-a-jpeg-image-from-memory-… but grep -r jpeg_tag in boost/gil gives nothing (same with image_read_settings) and read_image has no documentation and not the same signature. Anyone knows something about that? F

3 4

building boost 1.67/1.68b1 on osx with emscripten 1.38
by danielle amethyst brake 25 Jul '18

25 Jul '18

Hey Boost, I am trying to build Boost, ideally in its entirety, with emscripten. I am using emscripten 1.38.8, and either Boost 1.67 or the 1.68.b1, and am on OSX 10.13. Both Boost versions fail. I bootstrapped as normal (`./bootstrap.sh`), and then invoke b2 to build. i want C++14, so invoke as ./b2 toolset=emscripten cxxflags=-std=c++14 I get this long message with the roadblock at the end: Performing configuration checks - default address-model : 32-bit - default architecture : none Building the Boost C++ Libraries. - symlinks supported : yes error: No best alternative for libs/context/build/asm_sources next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>elf <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>elf <threading>multi <toolset>qcc not matched next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>mach-o <threading>multi <toolset>clang not matched next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>mach-o <threading>multi <toolset>darwin not matched next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>pe <threading>multi <toolset>msvc not matched next alternative: required properties: <abi>aapcs <address-model>64 <architecture>arm <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>aapcs <address-model>64 <architecture>arm <binary-format>elf <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>aapcs <address-model>64 <architecture>arm <binary-format>mach-o <threading>multi <toolset>clang not matched next alternative: required properties: <abi>aapcs <address-model>64 <architecture>arm <binary-format>mach-o <threading>multi <toolset>darwin not matched next alternative: required properties: <abi>o32 <address-model>32 <architecture>mips1 <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>o32 <address-model>32 <architecture>mips1 <binary-format>elf <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>mach-o <threading>multi <toolset>darwin not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>xcoff <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>xcoff <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>elf <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>mach-o <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>mach-o <threading>multi <toolset>darwin not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>xcoff <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>xcoff <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>32_64 <architecture>power <binary-format>mach-o <threading>multi not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>elf <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>elf <threading>multi <toolset>intel not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>darwin not matched next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <threading>multi <toolset>clang not matched next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <threading>multi <toolset>clang-win not matched next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <threading>multi <toolset>intel not matched next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <threading>multi <toolset>msvc not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>intel not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>darwin not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>intel not matched next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <threading>multi <toolset>clang not matched next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <threading>multi <toolset>clang-win not matched next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <threading>multi <toolset>intel not matched next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <threading>multi <toolset>msvc not matched next alternative: required properties: <abi>x32 <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>x32 <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>x32 <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>intel not matched next alternative: required properties: <abi>sysv <address-model>32_64 <architecture>x86 <binary-format>mach-o <threading>multi not matched next alternative: required properties: <abi>sysv <architecture>combined <binary-format>mach-o <threading>multi not matched - C++11 mutex : yes - lockfree boost::atomic_flag : yes - Boost.Config Feature Check: cxx11_hdr_tuple : yes - Boost.Config Feature Check: cxx11_lambdas : yes - Boost.Config Feature Check: cxx11_noexcept : yes - Boost.Config Feature Check: cxx11_nullptr : yes - Boost.Config Feature Check: cxx11_rvalue_references : yes - Boost.Config Feature Check: cxx11_template_aliases : yes - Boost.Config Feature Check: cxx11_thread_local : yes - Boost.Config Feature Check: cxx11_variadic_templates : yes - Boost.Config Feature Check: cxx11_auto_declarations : yes - Boost.Config Feature Check: cxx11_constexpr : yes - Boost.Config Feature Check: cxx11_defaulted_functions : yes - Boost.Config Feature Check: cxx11_final : yes - Boost.Config Feature Check: cxx11_hdr_mutex : yes *Error: ambiguity found when searching for best transformation* *Trying to produce type 'SEARCHED_LIB' from: * *Generators that succeeded:* * - searched-lib-generator* * - emscripten.searched-lib-generator* *First generator produced: * * - { %.no-action-icudata.SEARCHED_LIB }* *Second generator produced: * * - { %.no-action-icudata.SEARCHED_LIB }* I can get past this error by disabling icu, with ./b2 toolset=emscripten cxxflags=-std=c++14 --disable-icu but i just get a similar error. *Error: ambiguity found when searching for best transformation* *Trying to produce type 'SEARCHED_LIB' from: * *Generators that succeeded:* * - searched-lib-generator* * - emscripten.searched-lib-generator* *First generator produced: * * - { %.no-action-z.SEARCHED_LIB }* *Second generator produced: * * - { %.no-action-z.SEARCHED_LIB }* of course, using c++14 doesn't affect my problem whatsoever. can anybody help me? -- Danielle Brake Assistant Professor of Mathematics University of Wisconsin Eau Claire danibrake.org she/her/hers

2 1