C++14

Hi,

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: isocpp.org

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 0b10010001000001000 and digit separators to make for instance binary literals readable 0b1_0010_0010_0000_1000. There were very annoying problems with digit separators versus user defined literals (think the UDL _3d 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.

Cheers,
Axel

Make "Function Pointer",

  • 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.

How about designated initializers?

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

Re: designated initializers

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

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.

Re: back tick

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

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: - http://dlang.org/ - http://dlang.org/comparison.html - http://dpaste.dzfl.pl/ - D is a dragon, or why D matters for Bioinformatics http://blog.thebird.nl/?p=93

For me D is nice "toy"

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 !!!

Re: D

Hi,

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.

Toy language vs Legacy Bloating

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.

reflection !!!

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

Re: reflection

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

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++?

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

Re: OpenC++

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.

Work at CERN, in C++/ROOT team

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!

Re: Work at CERN

Hi Imax!

Thanks for your interest! All the official recruitment information is here: ert.cern.ch. 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