C!! — A C++ Variant For High Performance Programming (aka C bang bang)

So for a while now I’ve been talking about designing my own variant of C++ for videogames (in particular), but also for software development in general that targets heavy SIMD instruction use, is highly cache aware, and can be used to target specific processor architectures at compile time. The idea is to throw away some of the cruft from C++, and bring in some new features.

I started thinking about this in 2009 (the elements had all been there as far back as 2006, as I’d have long discussions with John Cuyle when we worked at Surreal about language design, and how C++ was basically hitting a wall unless it evolved – some of the features I wanted were really language features). I had a few discussions with Rebecca Heinemann, Adam Schaeffer, Kev Gee and David Tuft when we worked together in ATG about it, and Jason Weiler as well. And for a while I just let it simmer. About 5 years.

Some of this was spurred on by Jonathan Blow’s recent talk where he discussed some ideas that cross its path, and more still by Mike Acton’s recent CppCon talk. So I think it’s an idea whose time has come.

Now you might be wondering “You work at Microsoft, why not just get them to do it?”

Well, for one, for it to be fully adopted, it can’t come out of Microsoft. Too many people will nay-say it. Secondly, Microsoft’s going in a different direction – look at C++/Cx, XAML and the Windows Runtime. It’s not incompatible, but it’s like they’re heading to San Francisco, and I’m heading to Los Angeles. Yes, they’re both in California, but they’re not really the same destination.

Thirdly, Microsoft is a huge place, and I’ve tried to kickstart ideas there before. Frankly, five years in and several attempts later,  I don’t feel like I have the street-cred to do it there (especially when there are plenty of other options to get work done now). Besides, it’d be nice to get fellow developers to hack on this first, and put together a spec that feels right, before trying to gather supporters for it.

So instead, let’s start out here – with the game development community – where we can hash out the idea in public.

You might be thinking “why C!!”?

Well, another way of saying “!” is “bang”. And C Bang-Bang sounds suitably gamey.

Warning: Going into this, this is going to be ropey. It’s not going to be well thought out. It’s meant to be a jam session. And it’s not often (ever?) that I put my foot down and say “my way or the highway”, but this is one of them. I get to be final arbiter on what this looks like. Feel free to fork it and steal ideas for your own language.

BTW: Yes, I’ve looked at D. Not bad. But it doesn’t have quite the bits I want. It has some elements. No, I’ve not looked at Go, Rust or anything else. That’s deliberate. I want something that looks and feels like C++ or C#, without introducing too many random rules/characters and side effects. Anything that is unexpected hopefully will be explicitly, verbosely, typed out. We all have auto-complete in our editors now… so….

… here we go.

Language features so far…

Here’s what I’ve got so far that I want to include. We’ll see how they turn out…

• Breaking backwards-compatibility with C++ as a feature, not a bug
• Remove rough cobwebby C++ corner cases wherever possible
• Explicit size native types as first-class citizens (uint64 not uint64_t)
• vector types for SIMD as first-class citizens
• Automatic declarative packing and endianness handling, including the ability to specify a compile-target and an output-target to make writing editor serialization easier (run on PC, target PowerPC? No problem. We handle the endianness conversions for you)
• Structure-of-Arrays as a first-class language construct
• Structure versioning
• Duck-typed contracts, with varying degrees of strictness.
• Maps, which define mappings between two different types (or contracts, or types and contracts)
• Transformation assignment operator to explicitly invoke a mapping (<==)
• Code DOM generation as first-pass output, fed into generator code blocks. (You write generator code which is compiled, and passed a code DOM of the rest of your code, which you can use to generate new code – like serializers. The process is recursive. The intent is that it’s compile-time only, and you could use it to implement the rest of the features)
• Lists and structure-of-array lists, which could handle a variety of different allocator patterns (particularly, strided allocation, to reduce TLB misses – so your structure-of-arrays would have the first N indices co-located on a memory page, and strided to keep common data across arrays on the same page).
• Data-table generation (for things like error codes, errors strings, and strongly typed errors, all defined in one place)
• MapReduce-like processing of arrays of objects, to reduce the cost of heavily branched code.
• Atomics as a first-class language feature
• Synchronization and threading as a first-class language feature (here be dragons, as it has to be flexible enough to change depending on today’s favorite flavor of concurrency modeling – and tomorrow’s)
• Removing template-metaprogramming as everyone’s first choice of hack around the lack of user-programmable compilers. (Let’s see if we can replace that entire class of problems with code generation).

If we’re looking at compiler/editor features, I’d like to see:

• Edit-time tokenization (and background compilation and linking), with realtime, rules-based prettification. Never argue about brace placement again!
• Auto-documentation of methods (with a pretty, HTML editor, inline)

… but those come way later.