November 2018 - Boost - lists.preview.boost.org

[release] Boost 1.69.0 Beta 1 Release Candidate 3
by Marshall Clow 17 Nov '18

17 Nov '18

[ Ok, I've rebuilt the RC - and it contains only the changes to function and MPL ] The release candidates for the third 1.69.0 beta release are now available at: <https://dl.bintray.com/boostorg/beta/1.69.0.beta1.rc3/source/> The release notes are not yet final. The SHA256 checksums are as follows: ee0ecd7d31f58474c1e0210089c9e66bd878d4d1e7436ac511e359aa4a9d3e86 ./boost_1_69_0_b1_rc3.7z 3e25c46f2171799caabbeb419ba7859fffb62208f3a1c80798713377ab07af0e ./boost_1_69_0_b1_rc3.tar.bz2 71f4b57175058af1b8c320971cf29226e5a652931a679f7e1c086655147ecafb ./boost_1_69_0_b1_rc3.tar.gz ec9ef7d2c9f0d41f560769e67bc7ff207cc999243a7dd6c3f6bcfbdbf0827a7b ./boost_1_69_0_b1_rc3.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

1 1

[spirit] Request to update the master branch with minor doc changes
by Nikita Kniazev 16 Nov '18

16 Nov '18

Do I have a chance to cherry-pick minor doc changes into the upcoming release? I forgot to update version numbers in docs https://github.com/boostorg/spirit/commit/b4f5833cc69f510d3842ba226d8878bb4…

2 1

[build] targeting different versions of libstdc++
by James E. King III 16 Nov '18

16 Nov '18

If I make a system with libstdc++6-dev, libstdc++7-dev, and libstdc++8-dev on it, is there a way to tell clang to use one over the other? By default it will use the latest one. I know that for linking one can use the clang flag "--gcc-toolchain=/usr/lib/gcc/x86_64-linux-gnu/7" to get the link to point at it, but I'm not sure if this also handles the header paths or not. If this option works for both header inclusion and for linking, would I need to specify it as <cxxflags> and also as <linkflags>? Thanks, Jim

2 1

[bjam] [build] Documentation for 1.69
by Cromwell Enage 16 Nov '18

16 Nov '18

Hi, everyone! Will the documentation for Boost.BJam and Boost.Build be included in the release of Boost 1.69? Cromwell D. Enage

5 7

Announcing LEAF, a new error handling library suitable for low latency applications
by Emil Dotchevski 15 Nov '18

15 Nov '18

LEAF (Low-latency Error Augmentation Framework) is a new error handling library which could possibly become the successor of Boost Exception, though LEAF can be used without exceptions too. Official documentation: https://zajo.github.io/leaf/ Features: - No dynamic memory allocations. - Associate objects of arbitrary types with any failure -- when it is initially reported or at a later time. - Compatible with std::error_code, errno and any other error handling API. - Use with or without exception handling. - Support for multi-thread programming. Emil

4 9

Re: [boost] [Boost-users] [release] Boost 1.69.0 Beta 1 Release Candidate 1
by Marshall Clow 14 Nov '18

14 Nov '18

On Mon, Nov 12, 2018 at 4:30 PM Tom Kent via Boost-users < boost-users(a)lists.boost.org> wrote: > > On Mon, Nov 12, 2018 at 9:36 AM Marshall Clow via Boost-users < > boost-users(a)lists.boost.org> wrote: > >> The release candidates for the first 1.69.0 beta release are now >> available at: >> >> <https://dl.bintray.com/boostorg/beta/1.69.0.beta.1.rc1/source/> >> > 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. >> > > toolset arch compile Link Execute > msvc-8.0 32 FAIL X X > msvc-8.0 64 FAIL X X > msvc-9.0 32 X X X > msvc-9.0 64 X X X > msvc-10.0 32 X X X > msvc-10.0 64 X X X > msvc-11.0 32 X X X > msvc-11.0 64 X X X > msvc-12.0 32 X X X > msvc-12.0 64 X X X > msvc-14.0 32 FAIL X X > msvc-14.0 64 FAIL X X > msvc-14.1 32 X X X > msvc-14.1 64 X X X > > Compile means that the b2 command completed without errors > Link means that visual studio was able to link a sample executable to a > library (libboost_thread-vcXXX-mt[-gd]-1_XX.lib) > generated > Execute means that the linked program executed without errors. > > Full build logs can be found here: > https://gist.github.com/teeks99/526cf2598d1697557e45e590ce9517be > > Lots of errors with msvc-8.0: > > compile-c-c++ > bin.v2\libs\log\build\msvc-8.0\release\link-static\threadapi-win32\threading-multi\trivial.obj > trivial.cpp > .\boost/parameter/aux_/arg_list.hpp(227) : error C2064: term does not > evaluate to a function taking 1 arguments > .\boost/parameter/aux_/arg_list.hpp(390) : see reference to class > template instantiation 'boost::parameter::aux::arg_list<TaggedArg,Next>' > being compiled > > If there is an easy way to fix arg_list.hpp that would be nice, but if > this is the time to stop build 8.0, that's fine too. > > Also numerous errors for many (all dlls?) of the libraries with msvc-14.0. > They all look something like this: > > > msvc.link.dll > bin.v2\libs\atomic\build\msvc-14.0\release\threading-multi\boost_atomic-vc140-mt-x32-1_69.dll > Creating library > bin.v2\libs\atomic\build\msvc-14.0\release\threading-multi\boost_atomic-vc140-mt-x32-1_69.lib > and object > bin.v2\libs\atomic\build\msvc-14.0\release\threading-multi\boost_atomic-vc140-mt-x32-1_69.exp > msvc.link.dll > bin.v2\libs\system\build\msvc-14.0\release\threading-multi\boost_system-vc140-mt-x32-1_69.dll > Creating library > bin.v2\libs\system\build\msvc-14.0\release\threading-multi\boost_system-vc140-mt-x32-1_69.lib > and object > bin.v2\libs\system\build\msvc-14.0\release\threading-multi\boost_system-vc140-mt-x32-1_69.exp > msvc.link.dll > bin.v2\libs\container\build\msvc-14.0\release\threading-multi\boost_container-vc140-mt-x32-1_69.dll > Creating library > bin.v2\libs\container\build\msvc-14.0\release\threading-multi\boost_container-vc140-mt-x32-1_69.lib > and object > bin.v2\libs\container\build\msvc-14.0\release\threading-multi\boost_container-vc140-mt-x32-1_69.exp > msvc.manifest.dll > bin.v2\libs\atomic\build\msvc-14.0\release\threading-multi\boost_atomic-vc140-mt-x32-1_69.dll > 'mt' is not recognized as an internal or external command, > operable program or batch file. > > if exist > "bin.v2\libs\atomic\build\msvc-14.0\release\threading-multi\boost_atomic-vc140-mt-x32-1_69.dll.manifest" > ( > call "bin.v2\standalone\msvc\msvc-14.0\msvc-setup.bat" x86 >nul > mt -nologo -manifest > "bin.v2\libs\atomic\build\msvc-14.0\release\threading-multi\boost_atomic-vc140-mt-x32-1_69.dll.manifest" > "-outputresource:bin.v2\libs\atomic\build\msvc-14.0\release\threading-multi\boost_atomic-vc140-mt-x32-1_69.dll;2" > ) > > ...failed msvc.manifest.dll > bin.v2\libs\atomic\build\msvc-14.0\release\threading-multi\boost_atomic-vc140-mt-x32-1_69.dll > bin.v2\libs\atomic\build\msvc-14.0\release\threading-multi\boost_atomic-vc140-mt-x32-1_69.lib... > ...removing > bin.v2\libs\atomic\build\msvc-14.0\release\threading-multi\boost_atomic-vc140-mt-x32-1_69.dll > ...removing > bin.v2\libs\atomic\build\msvc-14.0\release\threading-multi\boost_atomic-vc140-mt-x32-1_69.lib > > I'm on the fence if we should continue supporting 8.0, so if that doesn't > get fixed then no big deal. However the issue with (the build tool?) for > 14.0 seems like a showstopper for this RC. > > Do we have any idea why MSVC 14 is failing? -- Marshall (who has been distracted by WG21 stuff)

4 4

What part of "The master branch is closed except by explicit permission" is confusing?
by Marshall Clow 14 Nov '18

14 Nov '18

That means "DO NOT COMMIT TO THE MASTER BRANCH" FULL STOP. I just turned on the auto-updating for the release, expecting two changes: * one from MPL * one from Function. Instead, I got updated from: * Update mpl from master * Update function from master * Update atomic from master * Update log from master * Update convert from master * Update iostreams from master You're making the release process harder. -- Marshall

3 2

Re: [boost] [Boost-users] [release] Boost 1.69.0 Beta 1 Release Candidate 1
by Marshall Clow 14 Nov '18

14 Nov '18

On Wed, Nov 14, 2018 at 9:02 AM Edward Diener via Boost-users < boost-users(a)lists.boost.org> wrote: > On 11/14/2018 11:06 AM, Marshall Clow via Boost-users wrote: > > On Mon, Nov 12, 2018 at 4:30 PM Tom Kent via Boost-users > > <boost-users(a)lists.boost.org <mailto:boost-users@lists.boost.org>> > wrote: > > > > > > On Mon, Nov 12, 2018 at 9:36 AM Marshall Clow via Boost-users > > <boost-users(a)lists.boost.org <mailto:boost-users@lists.boost.org>> > > wrote: > > > > The release candidates for the first 1.69.0 beta release are now > > available at: > > > > <https://dl.bintray.com/boostorg/beta/1.69.0.beta.1.rc1/source/> > > > > 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. > > > > > > toolset arch compile Link Execute > > msvc-8.0 32 FAIL X X > > msvc-8.0 64 FAIL X X > > msvc-9.0 32 X X X > > msvc-9.0 64 X X X > > msvc-10.0 32 X X X > > msvc-10.0 64 X X X > > msvc-11.0 32 X X X > > msvc-11.0 64 X X X > > msvc-12.0 32 X X X > > msvc-12.0 64 X X X > > msvc-14.0 32 FAIL X X > > msvc-14.0 64 FAIL X X > > msvc-14.1 32 X X X > > msvc-14.1 64 X X X > > > > Compile means that the b2 command completed without errors > > Link means that visual studio was able to link a sample executable > > to a library (libboost_thread-vcXXX-mt[-gd]-1_XX.lib) > > generated > > Execute means that the linked program executed without errors. > > > > Full build logs can be found here: > > https://gist.github.com/teeks99/526cf2598d1697557e45e590ce9517be > > > > Lots of errors with msvc-8.0: > > > > compile-c-c++ > > > bin.v2\libs\log\build\msvc-8.0\release\link-static\threadapi-win32\threading-multi\trivial.obj > > trivial.cpp > > .\boost/parameter/aux_/arg_list.hpp(227) : error C2064: term does > > not evaluate to a function taking 1 arguments > > .\boost/parameter/aux_/arg_list.hpp(390) : see reference to > > class template instantiation > > 'boost::parameter::aux::arg_list<TaggedArg,Next>' being compiled > > > > If there is an easy way to fix arg_list.hpp that would be nice, > > but if this is the time to stop build 8.0, that's fine too. > > I have essentially backed out a fix on 'develop' for VC++8.0 which > intended to fix another problem with a multiple definitions linking > error, https://github.com/boostorg/mpl/pull/36. > > I would like to push this change to 'master'. It should fix your problem > above with VC++8.0. I will subsequently take another look at the > original fix and see if it can not be corrected. > If you're confident that this will fix the problem, then please do so. -- Marshall

1 0

Re: [boost] [Boost-users] [release] Boost 1.69.0 Beta 1 Release Candidate 1
by Marshall Clow 14 Nov '18

14 Nov '18

On Wed, Nov 14, 2018 at 8:35 AM Edward Diener via Boost-users < boost-users(a)lists.boost.org> wrote: > On 11/14/2018 11:06 AM, Marshall Clow via Boost-users wrote: > > On Mon, Nov 12, 2018 at 4:30 PM Tom Kent via Boost-users > > <boost-users(a)lists.boost.org <mailto:boost-users@lists.boost.org>> > wrote: > > > > toolset arch compile Link Execute > > msvc-8.0 32 FAIL X X > > msvc-8.0 64 FAIL X X > > msvc-9.0 32 X X X > > msvc-9.0 64 X X X > > msvc-10.0 32 X X X > > msvc-10.0 64 X X X > > msvc-11.0 32 X X X > > msvc-11.0 64 X X X > > msvc-12.0 32 X X X > > msvc-12.0 64 X X X > > msvc-14.0 32 FAIL X X > > msvc-14.0 64 FAIL X X > > msvc-14.1 32 X X X > > msvc-14.1 64 X X X > [snip] > Lots of errors with msvc-8.0: > [snip] > This is a result of a change in MPL for VC++8. I will back out this change. > Appreciated. Please test locally, and we'll watch the bots. (Looks like we have two MSVC-8 bots) -- Marshall

1 0

What is status of Boost.Sync?
by Mateusz Loskot 13 Nov '18

13 Nov '18

Hi, The library docs docs say it's been in Boost since 1.55. Boost master has no submodule for it. Boost develop has submodule for it If Sync was removed, why it is still in develop? If Sync was added, hence it is in develop, why the docs mention 1.55 and why it is not in master? What is the status of this thing? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

Boost Test Matrix - no clang release builds?
by James E. King III 12 Nov '18

12 Nov '18

I was putting together some additional testing for a library and my CI jobs were failing in release mode. I was able to reproduce the issue locally. On examination of the boost test matrix however I was unable to see the same failures. When I dug into it a little bit more, it looks like the clang linux build jobs only build the default variant (debug), and therefore will not catch release-mode optimization issues when running the unit tests. Here's one of the job details: https://www.boost.org/development/tests/develop/teeks99-02-dc6-17-Docker-64… Given this matrix is the last line of defense before code is merged from develop to master, I'd suggest that the build jobs should all be targeting variant=release instead of variant=debug. The former directly impacts a release, and the latter does not. - Jim

4 3

[hash] Missing boost::hash_value for std::forward_list
by Alexander Zaitsev 11 Nov '18

11 Nov '18

Hello. Recently I found that boost::hash_value has no overload for std::forward_list. Who can tell me - why? Is there any reason and/or limitation? Thank you. -- Best regards, Alexander Zaitsev

1 0

[config] std::uncaught_exceptions
by Lorenzo Caminiti 11 Nov '18

11 Nov '18

Hello all, std::uncaught_exception (singular) is deprecated in C++17 and will be removed in C++20. std::std::uncaught_exceptions (plural) should be used instead. Will Boost.Config have a macro to detect if std::uncaught_exceptions is supported or not by the current compiler? (For example, Boost.Contract implementation uses std::uncaught_exception and it will need to use std::uncaught_exceptions on C++20 compilers instead.) Thanks. --Lorenzo

2 3

[release] 1.69.0 closed for Beta
by Marshall Clow 10 Nov '18

10 Nov '18

The master branch is now closed for all changes except by permission for the Beta release. Also, remember to add your libraries' changes to the release notes at: < https://github.com/boostorg/website/blob/master/feed/history/boost_1_69_0.q… > You can preview the release notes at: <http://www.boost.org/users/history/in_progress.html> Thanks, -- The Boost Release Team

1 0

[release] many release notes pending
by Joaquin M López Muñoz 09 Nov '18

09 Nov '18

Just a heads up about the existence of many umerged lib-specific release notes at: https://github.com/boostorg/website/pulls I seem to remember this same issue happened in 1.68. Maybe some other protocol is needed for handling release notes. Best Joaquín M López Muñoz

6 10

Suggestions for TMP/function introspection problem?
by Hans Dembinski 09 Nov '18

09 Nov '18

Hi all, I am trying to figure out how to solve an introspection problem since a few days, and I am not making progress. I could use some help, it is for boost.histogram. Maybe what I want is not possible... Here is my problem. I have some classes A, B, ... which have some overloaded methods, let's call them `foo`. struct A { void foo(int, char); void foo(bool, int, char); }; struct B { void foo(double); void foo(bool, double); }; I need a way to detect how many arguments the shorter methods has. If the shorter method is foo(Ts...), the longer method is always (bool, Ts...). This is guaranteed. I do not know what Ts... is, it can be anything. I cannot use boost::callable_traits, because an overloaded member function cannot be fetched by name using t = boost::callable_traits::args_t<decltype(&A::foo)>; // fails, overload is ambiguous Can't I match the member function with a template of the form something(bool, Ts...) somehow? Any ideas? Best regards, Hans

2 4

Re: [boost] Boost.Build check to see if cxxflags flag is supported?
by Peter Dimov 09 Nov '18

09 Nov '18

> Note 4: > > This should probably be a feature, like <position-independent>on, which > toolsets translate to -fPIC as appropriate. ... which will fix the case where a shared library uses a static library, but -fPIC is not applied to the static library.

3 3

clang-win, (Thin)LTO this time
by degski 08 Nov '18

08 Nov '18

Starting new thread. Substantial progress has been made towards the goal of compiling Boost with Clang/LLVM (clang-cl.exe, targeting MSVC). The latest PR in this respect by Peter has achieved this. The next step is to be also able to use lld (lld-link in case of clang-cl.exe targeting MSVC) to generate the Boost-libs (static/dynamic). The main interest, IMO, is to be able to use LTO (Thin or Full), which is not possible without the use of LLD. A secondary benefit appears to be faster link times (info from the lld manual). In order to build static ThinLTO-enabled libs, it suffices to pass <compileflags>-flto=thin in the project jam file. The archiving, though, needs to be done with lld-link.exe, passing /lib as the first option (this way it will act as lib.exe, while being able to handle the llvm-byte-code [lib.exe finds the so generated .obj-files to be corrupt]). At consumption time of the libs, lld-link needs to be used for linking. Hacking clang-win.jam:156 to: toolset.flags clang-win.archive .LD $(cond) : "\"C:\\Program Files\\LLVM\\bin\\lld-link.exe\"" /lib ; achieves this goal. I would like to ask (probably Peter) to have a look into whether this can be achieved "the proper way", i.e. to programmatically set that particular line to the required value for this use-case. degski -- *“If something cannot go on forever, it will stop" - Herbert Stein*

4 13

Boost.Build check to see if cxxflags flag is supported?
by James E. King III 07 Nov '18

07 Nov '18

I'm looking for an example for how I could check to see if "-fPIC" is supported for the compiler as part of project requirements. In some recent PRs that include building a static library which then gets included in a shared library, code needs to be built with "-fPIC" on supported platforms/toolsets. There is some code in gcc.jam to do this if the overall link mode is shared (note: this code is not in clang.jam!), but in this case the overall link mode is static, and a Jamfile wraps the result in a shared library, so the directives in gcc.jam are not applied. So at the top level Jamfile, I want to add a project requirement that basically says, "if the compiler supports <cxxflags>-fPIC then use it". Thanks, Jim

3 2

Deadline for 1.69.0 beta extended
by Marshall Clow 07 Nov '18

07 Nov '18

The deadline for closing the master branch for the 1.69.0 beta has been extended until Friday, November 9th. The final release date has not been changed. -- Marshall (who is at a WG21 meeting all week)

1 0

[release][predef] Permission to merge to master..
by Rene Rivera 07 Nov '18

07 Nov '18

I have a change that adds some missing version information for Cygwin OS detection < https://github.com/boostorg/predef/commit/62a50d3892789076272b771f560a419b9…>. Can I merge that to master? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

2 1

"peer reviewed" - Rights and responsibilities of maintainers
by Alexander Grund 07 Nov '18

07 Nov '18

I'm having trouble with a maintainer of a boost library over a PR and am seeking for clarification. Background (may be skipped): A bug was introduced into the library which I noticed in one of "my" (company) projects leading to a reproducible crash. However the scenario is not that common (although others have the same problem) so it wasn't noticed earlier. I analyzed the problem and created a minimum working example to reproduce this and then opened a PR with a fix. The maintainer did not comment on this for multiple months so given it IS complicated, I factored out additional PRs with tests I created to show the problem, so each PR is fairly small. In the result there were PRs with tests that failed on travis and the fix-PR which included the test-PRs and the fix and succeeded on travis (and all other CIs) and users reported success using this PR. Still no response from the maintainer on any PR. He then added an own test claiming to be enough, while I (as the author of the original tests) knew it wasn't as e.g. it didn't fail. (so what's it worth then?) Furthermore he added a commit changing unrelated stuff and ADDITIONALLY changing code I touched in the fix claiming that it would be the essence of my patch and fix the problems. Again I (as the author of the original patch) know that this is not true especially as the test-PRs still fail with his patch applied. So my point/problem is: Is the maintainer allowed to simply do changes as he wishes without any review at all? My expected procedure is: - Someone creates a PR - Maintainer (and optionally the community) reviews (and comments on) it - It eventually gets merged or rejected with comments why OR: - Someones else (including the maintainer) creates a contra-PR fixing the same problem - That author explains, how and why this fixes the same problem and why it is superior to the original PR - This gets reviewed and either PR gets merged Arguments were made, that this doesn't apply to accepted boost libraries as e.g. "it's [the maintainers] heads that got chopped off if something gets broken". I would challenge this by the simple example at hand: This boost library IS broken and it crashes MY application (and others). But I see no heads rolling. Furthermore: If the maintainer is allowed to patch and change as he wants without ANY review, how can Boost still be called "peer reviewed"? My trust in Boost stems from the extensive review a library has to undergo before it is included in Boost. If afterwards no review is happening or reviews are actively avoided (as in the current example), then the older a Boost library gets, the less trust I would have in it as more and more unreviewed changes get included. So again: What is the Boost course on reviews of existing libraries and the statement on the rights and responsibilities of maintainers? Thanks, Alexander Grund

15 52

[parameter] Go C++11 and above only, or keep C++03 support?
by Cromwell Enage 06 Nov '18

06 Nov '18

Hi, everyone. The end of section 3.2.1 of the current Boost.Parameter home page tutorial notes "that because of the forwarding problem, parameter::parameters::operator() can't accept non-const rvalues". I've submitted a PR to the develop branch on GitHub that would grant Boost.Parameter the ability to support perfect forwarding and eliminate this issue. However, the PR uses rvalue references (in parameter::keyword, parameter::parameters, and the code generation macros) and variadic templates (in parameter::parameters and the code generation macros). With the exception of BOOST_PARAMETER_TEMPLATE_KEYWORD, the PR would make Boost.Parameter a C++11 library. As a result--based on < http://pdimov.github.io/boostdep-report/develop/parameter.html#reverse-depe…>--the following Boost libraries known to use Boost.Parameter would also become C++11: Boost.Accumulators Boost.Convert Boost.Graph Boost.Heap Boost.Log Boost.MetaStateMachine or Boost.MSM Boost.Parameter_Python Boost.Signals2 I'd like to hear from everyone else, especially the maintainers and users of these libraries, if it's okay for Boost.Parameter to go C++11 and above only or if C++03 support is still necessary. Cromwell D. Enage

14 37

[testing] Lots of spurious test runners
by John Maddock 05 Nov '18

05 Nov '18

There are rather a lot of test runners that fail all tests due to setup errors: sandia-gcc-5.4.0-c++11 cc1plus: error: unrecognized command line option "-std=c++11" sandia-gcc-5.4.0-c++14 cc1plus: error: unrecognized command line option "-std=c++14" sandia-gcc-6.4.0-c++11 cc1plus: error: unrecognized command line option "-std=c++11" sandia-gcc-6.4.0-c++14 cc1plus: error: unrecognized command line option "-std=c++14" sandia-intel-16.0-c++11 /bin/sh: line 1: icpc: command not found sandia-intel-16.0-c++14 /bin/sh: line 1: icpc: command not found sandia-intel-16.0 /bin/sh: line 1: icpc: command not found sandia-intel-17.0-c++11 /bin/sh: line 1: icpc: command not found sandia-intel-17.0-c++14 /bin/sh: line 1: icpc: command not found sandia-intel-17.0 /bin/sh: line 1: icpc: command not found teeks99-02-dc3.1-11-Docker-64on64 /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/functional:2194:2: error: no type named 'type' in 'std::enable_if<false, void>' (and more errors from <functional> - the compiler appears to be unable to handle the std lib headers so I'm not sure what the point of testing it is?) igaztanaga-develop-gcc-3.4c++03 cc1plus.exe: error: unrecognized command line option "-fvisibility-inlines-hidden" cc1plus.exe: error: unrecognized command line option "-fvisibility=hidden" Best, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

4 3

interest in a flag library
by Masse Nicolas 05 Nov '18

05 Nov '18

Hi all, This is the first time I post on this mailing list :). I'm posting because i'd like to know if people would be interested in a library to treat enum types as flags. I find that's something which is lacking in the language since the introduction of strongly typed enums, and I've since written some code in order to do this. So far I've seen some discussion on this mailing list about that, but it doesn't seems that any library have been written yet. So do you think it is worth the effort of porting and documenting my code so that it can integrated into boost, or not? Regards, Masse Nicolas. PS: For those interested, the code consists of a flag class, and overloads operators like '|' or &. It can be used like this: enum struct option : uint { none = 0, first = 1, second = 2, third = 4, forth = 8 }; static constexpr flags<option> var1 = option::first; static constexpr flags<option> var2 = option::second | option::third; static constexpr auto var3 = var1 | var2; /* type will be resolved into flags<option> */ static constexpr auto var4 = option::first | option::second | option::third; /* works too */ int main() { std::cout << var1 << std::endl; std::cout << static_cast<uint>(var2) << std::endl; /* note that static_cast<int> won't compile since the underlying type is uint */ std::cout << (var3 & option::forth) << std::endl; std::cout << (var3 == var4) << std::endl; return 0; }

8 9