| Panel | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||
This policy is incorporated by reference into the DM C++ Coding Standard. Changes to this document are to be made only with the approval of the System Architect (ref:
|
The C++11 standard and the C++14 improvements to it bring a number of useful language features that make the resulting code more expressive, easier to read, and safer. They are becoming well-implemented and widespread.
C++11/14 features supported by the default compiler provided with the oldest operating system distribution commonly used to install the LSST Stack, currently gcc 4.8.3, may be used at will in .cc implementation files. They may be used in .h interface header files if:
- the usage is hidden from SWIG, either because they are not in method signatures or because they have been explicitly excluded with
#ifndef SWIG, or - SWIG has been empirically shown to work with the code (e.g. by successful buildbot run with appropriate Python-based test cases).
Background information
Instructions for using devtoolset-3 to obtain a more modern gcc on the LSST cluster machines: https://confluence.lsstcorp.org/display/LDMDG/Developer+Tools+at+NCSA#DeveloperToolsatNCSA-AlternateDevelopmentEnvironment
C++11 compiler support matrix: http://wiki.apache.org/stdcxx/C++0xCompilerSupport
Following shows the trajectory from Proposal to final accepted DM Policy (shown above the horizontal rule ).
The following policy is proposed on the introduction of C++11 features to Data Management code:
- Features not supported by either the oldest supported gcc compiler (gcc 4.4 as of writing of this proposal) or clang 3.1, or where implementation incompatibilities exist between the two compilers, are explicitly forbidden
- The following C++11 features are explicitly permitted:
- Initializer lists: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2672.htm
- Static asserts: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1720.html
- auto keyword: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1984.pdf
- decltype: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2343.pdf
- Right angle brackets: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1757.html
- Variadic templates http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2242.pdf
- Defaulted/deleted functions: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2346.htm
- Default template arguments for function templates: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#226
- Extern templates: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1987.htm
- Strongly typed enums: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf
- Inline namespaces: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2535.htm
- C99 preprocessor: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1653.htm
- long long: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1811.pdf
- Features not explicitly forbidden nor permitted may be allowed on a case-by-case basis. Their use will require the approval of the System Architect.
- Subject to successful resolution of issues in ticket #2272, C++11 support will be enabled when compiling the stack with gcc
Comments
Jim Bosch
From: Jim Bosch <jbosch@astro.princeton.edu>
Subject: Re: [LSST-data] TCT proposal for introducing select C++11 features
Date: Sun, 2 Sep 2012 11:15:15 -0400
The list looks good to me. I do have a few comments:
- rvalue references are the kind of thing I would leave in the "case-by-case" category in general, but there are two situations I think we should consider explicitly allowing them: perfect function forwarding (very useful,and hard to misuse if you follow the idiom), and especially writing move constructors for classes so they can be safely moved by the new STL. The latter is important because the compiler-generated move constructor may not always be safe for classes that have nontrivial destructors.
- Do we want to discuss the C++11 standard library at the same time? Some of that will require a little work to make sure we convert the entire stack at once as we switch from boost-supplied features to standard library implementations (std::shared_ptr, std:.hash, std::tuple), but I'd love to start using e.g. unique_ptr.
Kian-Tat Lim
From: Kian-Tat Lim <ktl@slac.stanford.edu>
Subject: Re: [LSST-data] TCT proposal for introducing select C++11 features
Date: Sun, 2 Sep 2012 09:27:07 -0700
My comment would be that I think we need to update the style guide/coding standards, such as it is, to incorporate the new features. In particular, I think we should standardize the appropriate use of static asserts, auto, strongly typed enums, and long long. It seems to me that the other features are extensions that I presume will be used as needed.
Robert Lupton
From: Robert Lupton the Good <rhl@astro.princeton.edu>
Subject: Re: [LSST-data] TCT proposal for introducing select C++11 features
Date: Tue, 4 Sep 2012 10:13:12 -0400
Signed Data (PGP ) Rob Pike told us that google was pushing out new C++11 features gradually. I'm not quite sure why they did so, but it's probably worth thinking about what we gain by suddenly switching as a "big bang". Also, do we want to mandate the use of e.g. auto or just permit it (basically KT's point about our standards)?
The library question is interesting too --- no more boost::shared_ptr (if that is OK with swig [I think so])?
Jim Bosch
From: Jim Bosch <jbosch@astro.princeton.edu>
Subject: [LSST-data] upgrading third-party packages
Date: Tue, 04 Sep 2012 11:12:46 -0400
If we adopt compiling in C++11 mode in the near futures, we'll also have to upgrade boost at the same time (and include a custom patch).
I'd guess we'd probably want to do any "automatic" (w.r.t. TCT approval) third-party updates at the same time. Aside from bumping the Python minor release number (2.7.2 -> 2.7.3), what are the other packages we should be upgrading?
I'd also *really* like to see us address #2212 (enabling Python's built-in sqlite module and enabling IPython) at the same time.
Jeff Kantor
From: Jeffrey Kantor <jkantor@lsst.org>
Subject: Re: Reverse Engineering Support for C++11
Date: Tue, 4 Sep 2012 09:54:18 -0700
I think if there are strong reasons to move we should do so. We will need the UML reference design updated before FDR, but we can do that as manual updates. I expect to do a full review of the design over this time frame, enough to update the model.