#CPPCON2017. Day 3. The Future of C++

 
Author:  Follow: TwitterFacebook
Job Title:Sarcastic Architect
Hobbies:Thinking Aloud, Arguing with Managers, Annoying HRs,
Calling a Spade a Spade, Keeping Tongue in Cheek
 
 

At #CPPCON2017 Day 3, I spent most of the time on the meetings of SG14 (on games and low-latency stuff); while it was certainly useful for me – the most interesting things on Day 3 happened outside of SG14.

Generative C++ == The Future

A name is a word of power if it is compilable

— Herb Sutter —

IMNSHO, the most important talk of Day 3 (and probably of the whole CPPCON2017) was the talk by Herb Sutter titled “Meta: Thoughts on generative C++”. I have a reputation of not being blindly sympathetic to the WG21 <wink />, but here I am saying: You guys are doing a Very Good Thing(tm) (and IMNSHO it is going to be the biggest C++ improvement since the advent of STL). 

Watching this talk is The Absolute Must(tm) when it becomes available on Youtube; it is The Direction where C++ goes (at least, I really hope so <wink />).

On the other hand – the length of the road we’re speaking about, is enormous (with full-scale generative C++ not coming IMO at least until 2030 or so):

  • Hare with smiley sign:in C++20, if we're lucky, we could get static reflectionin C++20, if we’re lucky, we could get static reflection (let’s root for it <smile />). This already will be a HUUUUGE improvement over what-we-have now, with stuff such as serialization, IDL generation,1 logging, and a dozen of the other similar scenarios becoming easily doable without any external stuff <phew />.
    • “spaceship operator”, which might make it there too, while improving things with the amount of boilerplate significantly (and I like it too), is not that fundamental change (and actually aims to fix one single problem).
  • The next planned step, if I understood Herb correctly, is “injection”. It is like compile-time C++ codegeneration within C++ itself. While being enormously powerful, it is not that straightforward to use. My guess is that while it will allow to do lots of things which are impossible now, to achieve those things we’ll have to abuse it a lot (well, hopefully not to the point of Turing-complete template metaprogramming – but still significantly). NB: while it will allow LOTS of things – it seems that we’ll still have to have cross-platform IDL outside of C++ (unless codegeneration will be generalized to externalizable arbitrary text – which doesn’t look to be among the goals)
Goals and non-Goals of Generative C++
  • And last but certainly not least – at some point we can hope to get an ability to classify our classes. One of the examples is specifying that certain thing is not a “class”, but is an “interface” – a specialized kind of class which disallows everything but pure virtual functions; or “value” (prohibiting member functions and enforcing everything public), and so on (make sure to watch the talk for further examples). Moreover, certain things (such as enums) can be expressed as specialized classes too (reducing the number of entities which have to be supported by the compiler, enums and enum classes becoming merely definitions within some include file in a standard library). Most importantly, however – we’ll be able to define things such as QtClass (with all the magic-currently-done-by-weird-templates, going into the perfectly legal C++-without-preprocessor).
  • Or, and last but not least – all these things are not changing the nature and the runtime behaviour of our C++ programs: they’re just a way to write things which we’re already able to write manually – just saving us time to write mundane things. 

Overall, I am very excited about this kind of the roadmap; the only concern of mine is a question when these beauties have a chance to happen. Even objectively, it is a Damn Lot(tm) of work, and that’s even without the need to jump through the hoops of the committee formalisms – and without the need to overcome resistance of conservatives-within-WG21, which, as we know from previous experience, have a potential slow things down by many years.

Good luck folks, you’ll certainly need it (but we’re keeping our fingers crossed for you).

May the Force be with you

1 though cross-language IDL generation will still require external IDL compiler

 

Hardware Designed for C++

[when designing Volta,] we were literally quoting C++ standard to each other

— Olivier Giroux , Nvidia —

Another IMO very important talk of Day 3 was that by Olivier Giroux from Nvidia, inconspicuously titled “Designing C++ Hardware”. While this talk may be seen as of only very niche importance, in fact – it does open a new era. The main message we got was that

Now, with transistors being cheap, it became possible to ensure compatibility of the hardware with programming-languages-higher-than-assembler – and hardware manufacturers are choosing C++

In addition to making us (as in “C++ developers”) feeling that we’re becoming even more important without lifting a finger <wink /> – it has profound implications on the C++ ecosystem:

  • Surprised hare:we cannot really think the world is limited to traditional few-cores-with-lots-of-RAM CPUs such as x64, ARM, SPARC, Power, etc.we cannot really think the world is limited to traditional few-cores-with-lots-of-RAM CPUs such as x64, ARM, SPARC, Power, etc. 2
    • In particular: with CPUs, a more-or-less-typical amount of RAM per core is in tens of gigabytes. With GPUs, we’re more in the range of hundred kilobytes (that’s 5 orders of magnitude difference!)
  • it provides an undisputable niche for C++ for many years to come (OTOH, we should be beware of the situation when HW manufacturers will get enough transistors to start supporting Ruby on their chips)

On more practical matters:

  • new nVidia Volta chip (and surrounding software) already almost allows writing C++ programs where a chunk of RAM is shared between CPU and GPU.
    • there are still quite a few quirks (=”DON’T expect to run your existing 100K-LoC library there – yet”), but we can hope for them to be sorted out in a not-so-distant future.
  • Unlike the rest of GPUs, on the outside Volta looks as a scalar processor. Not sure to which extent it really is (and whether we’ll still have to think about creating as-many-similarly-looking-threads-as-possible to make it efficient) – but in any case, it is a step into the direction of the making GPU programming more like usual C++ programming <phew />
Goals and non-Goals of Generative C++

Not sure about you – but I am certainly excited with this direction <smile />.

May the GeForce be with you <wink />

2 well, some of us are even guilty of thinking that the whole world is x64 <sigh />

 

SG14

Out of less fundamental (but hopefully coming much quicker) things I learned on Day 3, there are quite a few interesting things in progress by SG14 (games and low-latency programming):

  • support for non-blocking stuff
  • Hare thumb up:support for fixed-point is coming (including so-called 'elastic' fixed-point)support for fixed-point is coming (including so-called “elastic” fixed-point). From my perspective, the most interesting aspect of it is that it is going to be perfectly-deterministic <wow! />. With lots of things in MOG world hinging on next-to-impossible-to-achieve floating-point determinism – this is certainly a very interesting development.
  • support for interesting (and fast) data structures such as slot map [http://seanmiddleditch.com/data-structures-for-game-developers-the-slot-map/]. BTW, an interesting observation – in a sense, slot map can be seen as a close cousin of the id-checking technique for allocators in [http://ithare.com/allocator-for-reactors-with-optional-kinda-safety-and-relocation/].

Tired hare:It was another long day – and IMO the most exciting one so far. I hope to continue my coverage of CPPCON2017 tomorrow.

Join our mailing list:

Comments

  1. TheBuzzSaw says

    I loved Herb’s talk on “generative C++”, but it really caused me to pause and wonder if it’s a good idea right here right now. I seriously think that C++ needs a hard reboot before we go down this path. C++ will never go away, but I think it’s time to make a better language. Hear me out.

    The problem today is that every programming language that sets out to kill C++ ends up wandering off the path and solving different problems. Just look at Java and C#. They introduced amazing quality-of-life improvements over C++. No more preprocessor-driven organization! Packages and modules are way better than #includes and compilation units! High quality foreach mechanisms! Reflection! Generics! Type safety! But they couldn’t contain themselves and went the route of introducing garbage collection, virtual machines, unnecessary heap allocations, etc. So, instead of replacing C++, they merely went out to dominate specific business domains. They became a different way to program with a drastically reduced learning curve to make it accessible to more people at the cost of significantly more automation/safety.

    Is it too much to ask to have a “new C++” that gives us the good stuff and stops? The new language would stay true to what makes C++ awesome but only eliminate the stuff that wastes everyone’s time: compilation units, forward declaration, template metaprogramming (the bad parts), the pointer-reference dichotomy, etc. This would also be a rare opportunity to deprecate and remove a ton of cruft. We can give the language features that make sense in today’s hardware. We can introduce a sane namespace paradigm. We can have much of what makes Java/C#/etc. great without crossing the line and losing the ability to speak to the hardware.

    And can we get rid of exceptions? Let’s get rid of exceptions. How about some pattern-matching?

    Once the language is cleaned up, *then* I’ll feel better about all this ultra meta programming that Herb spoke of.

    • "No Bugs" Hare says

      Well, regardless of what we discuss here, deprecating stuff (especially as-widely-used-stuff as pointers/references) is not going to happen. With all the efforts and sacrifices WG21 has made to keep compatibility going back all the way to C (and BTW, objectively it _was_ one of the reasons for initial C++ popularity) – I don’t see any chance in hell to get these things deprecated.

      IMO, the best we can hope for in this regard, is ability to set (and enforce!) per-project guidelines. Imagine a bright future world, where we can say “hey, there are no C-style casts (pointers, references, SFINAE trickery, you-name-it) in this project” – and a source control, aided with guidelines checker (a customizable version of Core Guidelines Checker) just won’t allow to check in any code which uses C-style casts/whatever-else-we-prohibited! I contend this would be a MAJOR improvement for TONS of projects. IMNSHO, it would change landscape _tremendously_ – and will allow to _effectively_deprecate_ things on per-project basis, while keeping all the backward compatibility which C++ is traditionally so proud of.

      Sure, this deprecate-features-per-project-via-customizable-guidelines approach won’t be _as_clean_ as effectively-creating-a-new-language-deprecating-LOTS-of-stuff – but it is MUCH more realistic (and is IMO MUCH more likely to succeed).

      BTW, any thoughts on “how we could make guideline checkers _customizable_ in practice” – are EXTREMELY welcome ;-).

Leave a Reply

Your email address will not be published. Required fields are marked *