[geometry] Planning switch to C++11
Hi, We are planning to switch Boost.Geometry to C++11 https://github.com/boostorg/geometry/issues/590 Is the following procedure sensible: 1. Warn users on the Boost mailing lists about the planned switch to C++11 2. Make the switch (update the codebase) 3. Release the Boost.Geometry as C++11 e.g. with Boost 1.75 4. Announce on the Boost mailing lists that Boost.Geometry requires C++11 Are there any recommendations or requirements on how we should proceed? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Mateusz Loskot wrote:
Are there any recommendations or requirements on how we should proceed?
Yes, https://pdimov.github.io/articles/phasing_out_cxx03.html#_suggested_policy
On Wed, 25 Mar 2020 at 19:10, Peter Dimov via Boost
Excellent, thanks! I see that I missed it in the archive of the not-so-distant past https://lists.boost.org/Archives/boost/2019/11/247290.php Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Hi, as Boost.Nowide is now release ready and will be included in the 1.73 release I wanted to announce that I'm planning to require C++11 for anything after. There are a few minor things which need different other libs of Boost for C++98 support and given the age of C++11 support in especially MS compilers I want to reduce the dependencies to (almost) nothing. I say "MS compilers" because this is a Windows-centric lib and will most likely most often be used with MSVC. However I'll evaluate supporting even some older MSVC versions making some C++11 features optional if possible. Best Regards, Alexander Grund
On Thu, 26 Mar 2020 at 02:50, Alexander Grund via Boost < boost@lists.boost.org> wrote:
Is there support for C++17 <filesystem>? There are a few minor things which need different other libs of Boost
Don't do that.
-- @systemdeg "We value your privacy, click here!" Sod off! - degski "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey
On Thu, 26 Mar 2020 at 11:38, Alexander Grund via Boost
By specifying cxx11 features as required in test/Jamfile For example: https://github.com/boostorg/mp11/blob/develop/test/Jamfile#L15 https://github.com/boostorg/gil/blob/develop/test/Jamfile#L57-L63 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
The feature I require does not yet exist. I need movable std streams which MSVC supports since 2015 but 2013 does support most (many) C++11 features already. So checking other features is not reliable. I don't know enough about B2 to implement such thing myself. It seems to be Boost.Config providing those but most checks rely on Boost macros or std feature tests. There is neither for this. Best Regards
On Thu, 26 Mar 2020 at 11:54, Alexander Grund via Boost
Listing any cxx_* features which are not supported by VS 2013 should allow to filter 2013 and let the matix skip the builds. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
On Thu, 26 Mar 2020 at 13:02, Mike via Boost
Certainly, a compiler-specific filtering can be scripted in Boost.Jam. Here is a possible solution project : requirements <conditional>@disable-old-compiler ; rule disable-old-compiler ( properties * ) { local result ; if <toolset>msvc in $(properties) { # MSVC++ 12.0 (Visual Studio 2013) if toolset-msvc:version12.0 in $(properties) { echo ****** This MSVC++ version is too old ****** ; result = <build>no ; } } # else if for other oldies return $(result) ; } My Boost.jam fu is very limited, so there likely is a better solution. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Alexander Grund wrote:
You can look at https://github.com/boostorg/iostreams/commit/601244b26aba14a2524ab1307243d0c... as an example of writing such a custom check. Basically, you write a source file that compiles when the feature you want is available, then use check-target-builds to add a conditional requirement.
On Thu, 26 Mar 2020 at 12:27, Adam Wulkiewicz via Boost
The macros are useful but only if you want to support multiple C++ versions simultaneously, 03 and 11, etc. In such case you rather want a feature-specific macro anyway, as it is also self-documenting and makes clear what kind of workaround you apply. The config checks are b2 mechanism. For Jamfile, an all-in-one check would be useful indeed e.g. [ requires cxx11 ] Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
On 2020-03-26 14:26, Adam Wulkiewicz via Boost wrote:
This would not be practical, as probably no compiler implements the standard fully and without bugs. And you most probably not using every C++ feature either, so you're interested in some subset of features.
participants (7)
-
Adam Wulkiewicz -
Alexander Grund -
Andrey Semashev -
degski -
Mateusz Loskot -
Mike -
Peter Dimov