Changes between Version 6 and Version 7 of RFC5


Ignore:
Timestamp:
Mar 29, 2017, 1:56:04 PM (7 years ago)
Author:
mloskot
Comment:

Shuffle sections. Add Issues

Legend:

Unmodified
Added
Removed
Modified

  • RFC5

    v6 v7  
    3030A social factor: since C++ programmers no longer enjoy C++98, allowing C++11 mode may increase potential for new contributions.
    3131
    32 == Plan ==
    33 
    34 This proposal only requests agreement for the C++11 compilation mode.
    35 
    36 This proposal does not suggest any detailed roadmap of big refactoring committed in one go.
    37 
    38 The GEOS codebase is around 150 KLOC and given the available man-power to LOCs ratio, such one-step refactoring would not be feasible.
    39 
    40 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.
    41 
    42 **IMPORTANT**: C++11 refactoring must not change the C API or break C API compatibility, unless agreed upon based on prior RFC proposed.
    43 
    44 However, if the proposal is accepted, any new C++ code written for GEOS can be C++11-compliant.
    45 
    46 Prior acceptance of this proposal is necessary in order to start any source code refactoring using C++11 features.
    47 
    48 Once accepted, first step will be to update the build configurations to require C++11-compliant compiler.
    49 
    5032== Release ==
    5133
    … …  
    7052||MSVC ||14.0+ (2015)||
    7153
     54== Plan ==
     55
     56This proposal only requests agreement for the C++11 compilation mode.
     57
     58This proposal does not suggest any detailed roadmap of big refactoring committed in one go.
     59
     60The GEOS codebase is around 150 KLOC and given the available man-power to LOCs ratio, such one-step refactoring would not be feasible.
     61
     62Instead, 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.
     63
     64**IMPORTANT**: C++11 refactoring must not change the C API or break C API compatibility, unless agreed upon based on prior RFC proposed.
     65
     66However, if the proposal is accepted, any new C++ code written for GEOS can be C++11-compliant.
     67
     68Prior acceptance of this proposal is necessary in order to start any source code refactoring using C++11 features.
     69
     70Once accepted, first step will be to update the build configurations to require C++11-compliant compiler.
     71
     72
     73== Issues ==
     74
     75This section outlines issues potentially caused by upgrade to C++11 language.
     76
     77* C++11 destructors, by default, have now the new exception specification of `nothrow(true)`. Destructors of GEOS 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 GEOS codebase would find the program terminating whenever GEOS destructor throws an exception. Such review would be beneficial anyway.
    7278
    7379== References ==