Changes between Version 1 and Version 2 of rfc68_cplusplus11

Timestamp:

Apr 11, 2017, 3:16:30 PM (7 years ago)

Author:

Kurt Schwehr

Comment:

Initial draft that is a blend of text from GEOS RFC 5 and RFC 46: GDAL/OGR unification. There is a long ways to go yet. Broke links to avoid getting rejected as spam

rfc68_cplusplus11

@@ -1 @@
-RFC 68: C++11 Compilation Mode
+= RFC 68: C++11 Compilation Mode =
+
+|| Author:  || Kurt Schwehr ||
+|| Contact: || schwehr@google.com / schwehr@gmail.com ||
+|| Started: || 2017-Apr-11 ||
+|| Status:  || '''Work-In-Progress''' ||
+
+This RFC is based on trac.osgeo.org/geos/wiki/RFC5 GEOS RFC 5
+by Mateusz Łoskot.
+
+== Summary ==
+
+The document proposes to switch to
+en.wikipedia.org/wiki/C%2B%2B11 C++11 compilation mode as
+default throughout the whole C++ source code of GDAL.
+
+The goal of the document is to request and achieve agreement on using
+C++11 as the minimum required version of the C++ programming language
+standard.
+
+== Motivation ==
+
+The C++11 is the first major update of the C++ standard  since 1998. (C++03 was a bug fix release.)
+
+The C++11 features aim to promote writing clean, compact, type-safe and fast code. It also delivers better feature-wise compatibility with C language (C99).
+
+The Wikipedia article at en.wikipedia.org/wiki/C++11 does a great job describing all changes in  C++11 extensively.
+
+The `std::auto_ptr` smart pointer, together with a bunch of other features, has been deprecated and will be removed from C++17.
+
+The new compilers provide better diagnostics.
+
+Enabling C++11 compilation mode will improve the programming environment making it much friendlier than C++98.
+
+A social factor: since (many) C++ programmers no longer enjoy C++98, allowing C++11 mode may increase potential for new contributions.
+
+== Compilers Landscape ==
+
+Summary of compilers supported by GDAL with their minimal versions
+required to compile source code based on
+en.cppreference.com/w/cpp/compiler_support C++11 features.
+
+=== C++11 ===
+ 
+||GCC  ||4.8.1+      ||[https://gcc.gnu.org/projects/cxx-status.html#cxx11 C++11 status]    ||Debian 8 (stable), Ubuntu 15.04+, Ubuntu 14.04 `ppa:ubuntu-toolchain-r/test`, Fedora 19+, RHEL7 ||
+||Clang||3.3+        ||[https://clang.llvm.org/cxx_status.html#cxx11 C++11 status]          ||Debian 8 (stable), Ubuntu 14.04+, Fedora 19+, CentOS 6(?)||
+||MSVC ||12.0+ (2013)||[https://msdn.microsoft.com/en-us/library/hh567368.aspx C++11 status]||n/a||
+
+=== C++14 ===
+
+The C++14 compilers are listed for comparison only:
+
+||GCC  ||4.9+ ||
+||Clang||3.4+ ||
+||MSVC ||14.0+ (2015)||
+== Plan ==
+
+This proposal only requests agreement for the C++11 compilation mode
+switch in the current `trunk` branch only.
+
+If accepted, currently available build configurations (Autotools,
+CMake, NMake) will be updated to switch the compilation mode to C++11.
+
+This proposal does not suggest any detailed roadmap of big refactoring
+of the GDAL C++ codebase.
+
+The GDAL codebase is around 150 KLOC and given the available man-power
+to LOCs ratio, such one-step refactoring would not be feasible.
+
+Instead, the task will be tackled with the baby step approach
+gradually transforming the codebase according to priorities set along
+the way. Any disruptive refactoring, changes in interfaces of C++
+classes, breaking changes in C++ API must be announced and discussed
+on the mailing list or the bug tracker.
+
+'''IMPORTANT''': C++11 refactoring must not change the C API or break C
+API compatibility, unless agreed upon based on prior RFC proposed.
+
+However, if the proposal is accepted, any new C++ code written for
+GDAL can be C++11-compliant.
+
+Prior acceptance of this proposal is necessary in order to start any
+source code refactoring using C++11 features.
+
+Once accepted, first step will be to update the build configurations
+to require C++11-compliant compiler.
+
+== Issues ==
+
+This section outlines issues potentially caused by upgrade to C++11
+language.
+
+* C++11 destructors, by default, have now the new exception
+  specification of `nothrow(true)`. Destructors of GDAL classes should
+  be reviewed and any that are allowed/expected to throw exceptions
+  must be marked with `nothrow(false)`. Otherwise, any user of the
+  existing GDAL codebase would find the program terminating whenever
+  GDAL destructor throws an exception. Such review would be beneficial
+  anyway.
+
+== Release ==
+
+First release of GDAL with C++11 compiler requirement could be 2.3.0.
+
+=== C++14 ===
+
+This section clarifies status of C++14 support in GDAL.
+
+* Once C++11 is adopted as default compilation mode, GDAL developers
+  and maintainers must ensure it also successfully compiles in C++14
+  and C++17 modes.
+
+* Are contributors allowed to add `ifdef`'s for C++14 and C++17? No.
+
+* Is there a plan to upgrade to C++14 or C++17 to allow use of the C++
+  latest features? No, there is no plan. It is, however, recognized,
+  such motion may be put to the vote around 2020.
+
+== References ==
+
+* en.cppreference.com/w/cpp/compiler_support C++ compiler support
+
+== Self-assigned development constraints ==
+
+*TODO*
+
+The changes should have moderate impact on the existing GDAL/OGR code base, and
+particularly on most of its code, that lies in drivers.
+Existing users of the GDAL/OGR API should also be moderately impacted by the
+changes, if they do not need to use the new offered capabilities.
+
+== Core changes: summary ==
+
+'''TODO'''
+
+== Core changes: details ==
+
+'''TODO'''
+
+ * > > to >>
+
+=== Other ===
+
+'''TODO'''
+
+== Changes to Travis-CI ==
+
+== Changes to AppVeyor ==
+
+== Changes in drivers ==
+
+'''TODO'''
+
+== Changes in utilities ==
+
+'''TODO'''
+
+== Changes in SWIG bindings ==
+
+'''TODO'''
+
+The switch does not impact the `C` API used by the SWIG bindings.
+However, there may be some code that can be removed.
+
+  * Python and Java bindings:
+  * Perl and CSharp: make sure that it still compiles but some work would have
+
+== Potential changes that are *NOT* included in this RFC ==
+
+'''TODO'''
+
+"Natural" evolutions of current RFC :
+
+Further steps :
+
+== Backward compatibility ==
+
+'''TODO'''
+
+== Documentation ==
+
+'''TODO'''
+
+== Testing ==
+
+'''TODO'''
+
+Very few changes have been made so that the existing autotest suite
+still passes.  Additions have been made to test the GDALOpenEx() API
+and the methods "imported" from OGRDataSource into GDALDataset.
+
+== Version numbering ==
+
+'''TODO'''
+
+Although the above describes changes should have very few impact on existing
+applications of the C API, some behavior changes, C++ level changes and the
+conceptual changes are thought to deserve a 2.3 version number.
+
+== Implementation ==
+
+'''TODO'''
+
+Implementation will be done by Kurt Schwehr.
+
+== Related RFCs ==
+
+'''TODO'''
+
+There are a few related past RFCs that have never been adopted but strongly
+relate to RFC 68:
+  * trac.osgeo.org/geos/wiki/RFC5 GEOS RFC 5: C++11 Compilation Mode.
+    GEOS is switching to requiring C++11 to build.
+
+== Voting history ==
+
+No vote taken yet.