- Boost - lists.boost.org

Let's stop distributing binaries
by Robert Ramey 31 Aug '18

31 Aug '18

The fact is that users of boost use compilers with differing levels of C++ standard conformance. This creates a number of problems including (but probably not limited to) a) Using libraries built with different levels of C++ conformance may create ABI issues. b) it creates a discussion about "dropping C++03 support". Actually it creates a discussion about that the above actually means. c) It's motivated a suggestion that all libraries move to header only. This is not great idea - but I won't address that here. I believe all these issues - and more - would disappear if we just stopped distributing binaries. Each user would be building his own boost version with (presumably) the same compiler. Since C++03 compatible libraries are C++?? compatible, each library author can maintain the level of backward compatibility that he wishes. But if we're not going to distribute binaries, then users might as well just clone the latest "certified - good - tagged" version in the master branch from the github repo. That is, let's just stop or truncate the whole release circus. Replace with an occasional "certification/versioning procedure" which would make available a "squashed" master suitable for efficient cloning. This would make everyone's life easier. Robert Ramey

19 63

A possible date for dropping c++03 support
by Mike Dev 31 Aug '18

31 Aug '18

Sorry for all the bad line-breaks in my previous message. I don't have access to a properly configured email client right now. This should be easier to read: ====== Original Message ============== Please, let's not derail the discussion just after some consensus has emerged and just before it actually produces actionable items. Let's not make the better the enemy of the good here. I made the suggestion to commonly drop c++03 support in the hope that it would actually lead to some code simplifications and reduced coupling between the boost libraries - even if only in their implementation (if someone wanted to do a real c++14 reboot of their library, no one is/was stopping them anyway). >From the survey, I'd say interest in actually applying c++11 features in libraries that a currently supporting 03 is already relatively low, but big enough that I believe this will actually lead to some changes other than just changing the default test settings. That is with a standard almost universally supported by compilers in use today. Even though the move from 11 to 14 is much less dramatic, c++14 support is less wide spread and outside of the big three, there are many compilers where even the most recent version doesn't support c++14, so I just don't see people that are currently maintaining c++03 support in their libraries suddenly starting to use c++14. All this doesn't preclude a discussion about if and when to move to c++14 or a general policy about LTS versions and the like, but please keep it separate unless you are really, really confident it will lead to something actionable earlier than what is currently proposed. I have lots of Ideas, how boost could be reformed and/or modernized but in the end it comes down to convince the individual library maintainers to actually do something. I think the current proposal will at least spark some action. Let the announcement to move to cmake be a warning sign about realistic expectations about the evolution of boost. Maybe I'm aiming too low, but again, if you want more, please open a separate thread and most likely, whatever you come up with there will not be mutually exclusive with what is proposed here. Regarding the test settings: If c++11 is supposed to be the lowest official supported version then that is what should be tested Anything else doesn't make sense (you can't claim to support c++11 if you don't test if it actually works there). In any case, as was mentioned before, for the announcement itself we don't need give any specifics about something that is going to happen 1-1,5 years from now. How about something like " c++03 mode/compilation will no longer be tested / part off the general test/suit"? Best Mike

1 0

A possible date for dropping c++03 support
by Mike Dev 31 Aug '18

31 Aug '18

Please, let's not derail the discussion just after some consensus has emerged and just before it actually produces actionable items. Let's not make the better the enemy of the good here. I made the suggestion to commonly drop c++03 support in the hope that it would actually lead to some code simplifications and reduced coupling between the boost libraries - even if only in their implementation (if someone wanted to do a real c++14 reboot of their library, no one is/was stopping them anyway). >From the survey, Id' say interest in actually applying c++11 features in libraries that a currently supporting 03 is already relatively low, but big enough that I believe this will actually lead to some changes other than just changing the default test settings. That is with a standard almost universally supported by compilers in use today. Even though the move from 11 to 14 is much less dramatic, c++14 support is less wide spread and outside of the big three, there are many compilers where even the most recent version doesn't support c++14, so I just don't see people that are currently maintaining c++03 support in their libraries suddenly starting to use c++14. All this doesn't preclude a discussion about if and when to move to c++14 or a general policy about LTS versions and the like, but please keep it separate unless you are really, really confident it will lead to something actionable earlier than what is currently proposed. I have lots of Ideas, how boost could be reformed and/or modernized but in the end it comes down to convince the individual library maintainers to actually do something. I think the current proposal will at least spark some action. Let announcement to move to cmake be a warning sign about realistic expectations about the evolution of boost. Maybe I'm aiming too low, but again, if you want more, please open a separate thread and most likely, whatever you come up with there will not be mutually exclusive with what is proposed here. Regarding the test settings: If c++11 is supposed to be the lowest official supported version then that is what should be tested Anything else doesn't make sense (you can't claim to support c++11 if you don't test if it actually works there). In any case, as was mentioned before, for announcement itself we don't need give any specifics about something that is going to happen 1-1,5 years from now. How about something like " c++03 mode/compilation will no longer be tested / part off the general test/suit"? Best Michael

1 0

A possible date for dropping c++03 support
by Mike Dev 30 Aug '18

30 Aug '18

>From the discussion about abi compatibility when the Boost.System library is compiled e.g. in c++03 mode and then included in ac++11 project or vice versa (https://groups.google.com/forum/#!topic/boost-developers-archive/EWG5NVOZo_ g) > > When can we drop C++03 support? :D This will probably be ignored or shouted down, but maybe someone just needs to make a concrete suggestion about which people can discuss and vote so I'm giving it a shot: What about the first or second release in 2020 ? By then, all major toolchains have had solid c++11 support for at least 5 years ( I think, msvc was the last one with VS2015) and at least partial support for 7+ years (gcc 4.8, msvc 2013, clang 3.3). Also, most likely c++20 will be released in that year, which means that c++03 compatible libraries would have to support 5 different (and partial incompatible) language versions by then (not to mention ABI-compatibility considerations between different versions). That should also be enough time to ensure that the last c++03 release (late 2019) is really solid (for projects that still can't upgrade to c++11) and ideally there could be a few more bugfix-releases afterwards as is often done by other software projects. And before someone starts to raise straw mans: That of course wouldn't mean that a particular library *must* no longer compile in 03 mode, but one can no longer rely on the boost-internal dependencies remaining c++03 compatible. Best Mike

23 104

[ptr_container] associative container insert takes reference instead of const reference as key ?
by comic fans 30 Aug '18

30 Aug '18

Hello , I've found that ptr_unordered_map.insert has following signature (from code and latest doc) std::pair<iterator,bool> insert( key_type& k, T* x ); that forbids calls like ptr_unordered_map.insert( myobj->id(), myobj) ,I wonder if this is by design , or some other reason ? why other overload takes const key_type& k as key type? and insert always call insert_impl which have const reference as key type ? any help would be appreciated.

2 5

c++03 library survey
by Mike Dev 29 Aug '18

29 Aug '18

Hello everyone, this is closely related to the thread about "A possible date for dropping c++03 support" (https://groups.google.com/forum/#!topic/boost-developers-archive/i4UM-GfNu8w) but this is NOT meant as a vote on the suggestion, and I'd ask you to keep discussions to that thread. For the actually important part, please scroll down to the double line (===) For reference however, my suggestion was that c++03 support is officially dropped somewhere around early 2020 across all of boost. Which would mean, that from then onwards any library author could start to unconditionally use c++11 features in his library without prior announcement or transition period, even if other boost libraries that currently support c++03 have a dependency on it. (Again, if you have questions or comments about this, please answer on the other thread) Somewhat late, I realized I first should have asked if / how much actual interest there is from the side of the library maintainers in the first place, because whatever the majority of the people on the ML thinks, it obviously won't have any effect if the actually affected people don't have any interest in using c++11 in the first place. Full disclosure: I'm not a boost contributor myself (at least nothing significant) but as a user, I have an interest in boost libraries becoming simpler, less entangled with each other and providing less types that are redundant in c++11 and later. You could call that more lightweight but that is a different topic. So, to get some idea if there is any interest in this topic, I'd ask each maintainer that is currently maintaining a c++03 compatible library to answer the following questions: =======Please quote from here ====================================== - Which library/ies are you maintaining? (I assume this isn't some sort of private information - otherwise ignore the question) - Would you like to unconditionally use c++11 features if you would not have to worry about this breaking boost internal users? - Would you like to unconditionally use c++11 features if you would not have to worry about this breaking any users? - Would you deprecate your library completely if there were no boost-internal users and your current dependencies required c++11 (e.g. because your library has been merged into the c++11 standard library anyway) - Are you yourself using any boost library (in an up-to-date version) in a c++03, non-boost project? - Do you have any Idea if the latest versions of your library is used by any important/significant number of c++02 projects? [It is only important if *you* consider those projects important and or the number significant] =======Please quote till here ====================================== Note: When I'm talking about breaking users I mean breaking due to requiring c++11 compiler, not because you completely rewrite the API based on new c++11 idoms - that would probably better be done in a completely new library. Best regards and thank you for your time Mike

15 32

Re: [boost] A possible date for dropping c++03 support
by Glen Fernandes 29 Aug '18

29 Aug '18

Edward Diener wrote: > Other than not removing useful Boost libraries which support c++03 as > well as all subsequent C++ standard levels, and not telling people that > they can not use such libraries in c++03 mode if they actually want to > do so, I am perfectly willing to let others, including yourself, decide > the best way in which support for c++03 in Boost is reduced. My argument > has always been that putting a generalized statement on the website, > without explaining what it actually entails as far as using Boost l> ibraries is concerned, is going to lead to confusion and puzzlement > from end-users and endless questions. What can it possibly cost to > actually explain of what "Boost dropping support for c++03" actually > consists, when it is finally decided what Boost is going to do in this > area ? If it is a matter of correct grammar or exposition in the > explanation, I will gladly volunteer to write it if no one else wants to > do so. +1. It sounds like what we're going to communicate to users is that Boost library authors or maintainers are no longer required to make their libraries support C++03. Which sounds fine to me. I don't think library maintainers should be confined by users (even if the users are other Boost libraries) if they don't want to be. Any Boost library maintainers that wish to continue supporting their C++03 users will do so. Any other Boost library maintainers that depend on such libraries can drop the dependency on those libraries. Glen

3 3

Re: [boost] A possible date for dropping c++03 support
by Glen Fernandes 29 Aug '18

29 Aug '18

James King wrote: > I thought Peter Dimov got it right from the comment I saw earlier. > The project would no longer spend time and effort on qualifying or testing > C++03 compatibility. CI builds and the test matrix would no longer > specifically test C++03. The default language level for b2 builds would be C++11. Sounds right. All of these above is a much more useful statement to make to users. > Individual repository maintainers could attempt to continue to qualify > for C++03 however once an upstream dependency begins to include > C++11 code, that effort would have to give way. If an upstream dependency only works in C++11 and above, and the library maintainer wants to support C++03, they can either: A) Drop the dependency and still support C++03 B) Drop C++03 support But again it will be up to that library maintainer. > As a developer both working on and > consuming boost I would appreciate the permission to start using C++11 > without fear. You will be able to start using C++11 in the libraries that you maintain, without fear. You won't be able to force another library maintainer to let you use C++11 unconditionally in their library if they want to support C++03 users. Glen

1 0

BOOST_FOREACH on a filesystem directory_iterator?
by Peter Dimov 29 Aug '18

29 Aug '18

Boost.Filesystem apparently contains support for BOOST_FOREACH: https://github.com/boostorg/filesystem/blob/5a93351bfdf859ee47245e042973922… But it doesn't work: #include <boost/filesystem.hpp> #include <boost/foreach.hpp> namespace fs = boost::filesystem; int main() { fs::directory_iterator it; BOOST_FOREACH( fs::path const& p, it ) { } } 1>c:\boost-git\develop\boost/range/end.hpp(48) : error C2039: 'end' : is not a member of 'boost::filesystem::directory_iterator' The fix is trivial, but I wonder... how did nobody notice? Is this feature never used?

2 1

Future of the MaybeBoost Hash Library
by Ilia K 29 Aug '18

29 Aug '18

Hi! I was looking for a header-only library to compute SHA512 and found a very interesting project: The MaybeBoost Hash Library ( https://www.cs.mcgill.ca/~smcmur/hash/) that implements SHA/MD5 ect. In 2010 there was a discussion ( http://boost.2283326.n4.nabble.com/rfc-Preliminary-Hash-Library-td2668722.h…) about making it one of the Boost subprojects but nothing happened. Maybe some of you guys know what's the matter? -- - Ilia

2 1