You are here



Two weeks ago I participated at the ISO C++ standard meeting. It was my and CERN's first one and a pleasant surprise. A few news items:

  • The next two standards are planned for 2014 and 2017, with 2014 being a bit like 2003: mostly bug fixes and usability improvements.
  • There is now (thanks to CERN's presence :-) a working group on reflection in C++.
  • The next meeting will be in April, in Bristol. I will try to give a CERN computing seminar beforehand, such that we can collect your feedback on the proposals that will be discussed in Bristol.
  • There is a new web site on the future of the C++ standard:

Topics that were discussed in Portland were vectorization directives and parallel algorithms (sort etc). There were favorable votes on runtime-sized arrays

void f(int n) { int arr[n]; ...

, generic lambdas

[](auto a){ return ++a;}

, binary literals


and digit separators to make for instance binary literals readable


. There were very annoying problems with digit separators versus user defined literals (think the UDL


and hex numbers with digit separators), so the whole digit separator business is not yet resolved. For the others it's likely that they will at least end up in the 2017 standard.


Is there anything else you want to know? Ask, or watch Herb Sutter's live show tomorrow at 12:45 Pacific Time == 20:45 CERN time.



  • Make "Function Pointer", "Member Function Pointer" and "Functor" one, and call it Delegate.
  • Also, make lambdas "capture list" compiler-deduce-able.

Thanks for your time.

That would be a great "usability improvement". Since they were in C99, I was astounded that they didn't make it into C++11.

Hi Eric,

Thanks for your comment! That's a good point. My personal assumption is that this has not been too hot for C++ because most "C compatible structs" have become very rare in C++ code out there. And C++ structs offer different mechanisms for initialization.

Being as new to the committee as I am I cannot tell whether designated initializers have been discussed. I will ask in Bristol. That said, Doug Gregor (a real smart guy, like most of the other committee members) warns about this.

Cheers, Axel

How about the back tick ` for digit separators. That's an ASCII character that's not used by C++ yet as far as I know so that it doesn't conflict with anything.

Hi Lode,

Good idea! That was in fact one of the options discussed - including its major drawback that the back tick is not yet part of the C++ character set...

Cheers, Axel

D programming language does already all these thing and it is much lesser complex than C++. Since i use D for me i cn't come back to C++ . If you compra D and C++ they are two case: - C++ and D is equivalent for given feature - D is better for given feature So they are no reason to continue with this language External ressource: - - - - D is a dragon, or why D matters for Bioinformatics

Stop the world garbage collector. Compatibility with existing C++ libraries, in particular, gui libraries.

For me D is nice "toy" Language. It has a lot of great features that I wish would also be available in C++ too. The problem is that D is too small to be used. There is no gut IDE sot D like Visual Studio or XCode for C++. There is no solid highly optimized compilers for D. Like Clang or Intel C++ compilers. Yes I know there is D compiler in work based on LLVM but it is not mature enough. There are no tons of libraries for D and it is not possible to use C++ together with D. So for now there is no reason for me to use D even if it looks really gut. As opposite C++11 is now even better C++ and Clang has already solved a lot of problems with is. With Cling we even have REPL for C++11 !!!


Thanks for your comment (that I edited to correct a link)! There are many nice languages out there, also compiled ones. Some people favor D, some Go, some something else. The main problem with all these languages: educating thousands of students to learn it risks being a waste of time, see Tiobe (or any other index). Part two of the problem: who's going to rewrite the 50 million lines of C++ code that we have and rely on, in production, for large scale data analysis, in a million whatever-your-currency publicly funded endeavor? Anyone?

Until we have our code re-written in D, or until there is a language that is able to interface through headers with C++ (and is not threatening our investment through vendor lock-in) we'll have to stick to C++. Maybe we're unique in this respect, but I doubt that. Yes, I find oneway streets and our inability or inertia to move (e.g. to C++11!) frustrating too, but it's reality that we have to cope with.

Cheers, Axel.

Hi, I'm afraid that's a backward thinking so prevalent in the software industry. I'm experienced (15+ yrs) C++ developer and the fact is, that C++ remaining the native industry standard programming language has adverse effects on this industry. C++ has major disadvantages which won't go away with the new standards. The C++ inherited the C toolchain, however, while in C there's little issue with the compilation unit and included definition system, in C++, relying on OOP, it just doesn't cut it. No way, that this system will ever be abandoned in C++, but this is one of the major source of compilation time issues. The amount of legacy code justifies the reign of C++ at many companies, and the number hired C++ experts. Thus, as you also seem to promote, schools also feel to obliged to teach and focus on C++ in native land. C++ is too complex, too easy to make errors, too hard to make good tools for it. Just a fraction of the people who are working on C++ dev tools would be enough to run up a language like Go or D to a level where businesses would feel much to use it.

I think you don't know C++ enought to downgrade the value of it, by using brainwash Facts. C++ is a strict type language with multiparadyme that can be used as a C for high performance, as Java for object design, as Lisp for functionnal programming , as erlang for network programming, as ada for exception handler prgramming, as nim for event programming, etc... Not only it can do all with simple extension, boost, eigen, cairo, .. but to a higher level of each other language provide. The only exception is prototyping like R provide. C++ is a language that make thing easy to do, if you don't lost yourself into fancy stuff. You barely just play around with D or GO but are very far from high problems to solve , high level language only works for limited problems. R can't handle huge matrix operation, can't handle large file. D is very slow , can't handle network fast event, can't handle interruption, implicit a marshalling for OS call, etc.. We are not in any obligation to prove you anything , nor you don't need to feel to preach your narrow ideas.

This is great new. We finally will get Reflection in C++ !!!

Hi DevO,

Thanks for your enthusiastic comment! Note though that we will now discuss reflection for C++; whether and when it comes and what it will look like will be part of the discussion... Still: I agree that this is a huge first step!

Cheers, Axel.

Hi Axel, What we really need is C++ is Compiler Time "reflection" with minimal runtime overhead. Of course it would be great to have runtime "reflection" too but may be later... Customizable but not invasive. Should work with Libraries that you can not change. Something like "Rich Pointers" sound already interesting... Build into Compiler, no other tools are needed. Should be Optional, (on / off) compiler switch. I already started to use C++ reflection abed on Clang and this allow to do thing that appears to be impossible before. Sterilization in only small part of it. Cheers, Devid.

OpenC++ maybe what you are looking for. Unfortunately, it hasn't been updated since 2004.

Hi Kurt,

Thanks for your comment! I don't think we need more tools - we have tools. What we need is a runtime source of reflection, or language features that facilitate binding to such a library.

Cheers, Axel.

Hi Axel, slightly out of topic, but could you please mention what are the possibilities to get a job at CERN, in C++/ROOT team? Especially for those who are not fortunate enough to live in a CERN member state country. Thanks!

Hi Imax!

Thanks for your interest! All the official recruitment information is here: But if your passport comes from a non-member state then that's a lot more difficult.

Depending on your age, being a summer student can be an amazing experience. Else you'd have to convince us for instance through your patches that you know so much about cling that we'd like to have you over for a few months, where CERN could contribute to your subsistence. And who knows, our group might again apply for a few Google Summer of Code projects in 2013.

If you apply for anything then please let us know (ideally before submitting the application) so we can pick you out of the long :-) list of applicants! Hope to see you soon at CERN!

Cheers, Axel