wiki:DM/TCT/C++11Proposal
Last modified 5 years ago Last modified on 10/24/2014 09:01:27 PM

OBSOLETE

The file moved to: https://confluence.lsstcorp.org/pages/viewpage.action?pageId=20283399


Proposal to TCT: Policy on use of C++11 language features

C++11 standard brings a number of useful language features that make the resulting code more expressive, easier to read, and safer. It is becoming well implemented and wide-spread.

We propose the following policy on the introduction of C++11 features to Data Management code:

Resolution

Because it's not clear what swig supports, the TCT decided to allow the use of C++11 features only in .cc files. Furthermore, they were permitted as follows:

Background information

C++11 compiler support matrix: http://wiki.apache.org/stdcxx/C++0xCompilerSupport

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.