- Boost - lists.preview.boost.org

Original STL Library Documentation has been recovered and is now safe forever.
by Robert Ramey 02 Sep '18

02 Sep '18

The Standard Template Library is the foundation of modern C++. The creation and publication of this code and its documentation set a new standard for the formal specification of what a computer program should do, how it should be designed and how it should be formally documented. These pages were maintained first by Silicon Graphics and then later by Hewett-Packard. In January of 2018 these pages were removed by H-P. This is a historic blunder. I have recovered the original STL Library Document and hosted them here: http://www.rrsd.com/software_development/stl/index.htm Robert Ramey

8 10

[vcpkg] Support non-Windows build. #4169
by degski 02 Sep '18

02 Sep '18

FYI: https://github.com/Microsoft/vcpkg/pull/4169#issuecomment-417867673 degki -- *“If something cannot go on forever, it will stop" - Herbert Stein* *“No, it isn’t truth. Truth isn’t truth" - Rudolph W. L. Giuliani*

1 0

[integer] CMT assume responsibility for Boost.Integer?
by James E. King III 01 Sep '18

01 Sep '18

The maintainer of Boost.Integer has no commits since 2008, and I was unable to get a hold of him by email (waited 10 days for a reply). I suggest we transfer responsibility of this repository to the CMT. - Jim

3 3

Gsoc 2019
by Shubham Verma 01 Sep '18

01 Sep '18

Hey I'm new, but I'd like to contribute to your organisation, can someone please guide me along?

5 4

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