handmade.network » Forums » The Future of C++
John_Uskglass
Laurie
28 posts
#11385 The Future of C++
2 months ago

So now C++17 is getting pretty close to being done, I thought it might be interesting to have a discussion about what we, from a Handmade perspective, would like to see in the future of the language. If you're not aware of the C++17 features, there is a pretty good rundown here with code samples.

The reason I bring this up is that I'm aware that in some circles, including here and in many places in the games industry, there is quite a lot of negativity around the changes that have gone into the language since C++11. So my question to you all is, what would you like to see the standards committee doing to improve the language?

Whilst obviously I'm happy to discuss some of the more problematic changes to the language in the context of counter-examples, and of some of the cool features in possible alternative languages like Jai/Odin/Rust/Go/D etc., if at all possibly, I'd like to keep the focus on what positive changes would look like within the context of C++.

So yes, I'd really like to hear your thoughts on this! It would also be great if we could get the thoughts of people with very different levels of experience with C++, as I imagine that new C++ programmers might have a very different and interesting perspectives on this compared to more experienced C++ programmers. Hearing both would be great!
CaptainKraft
Jeremiah
133 posts
2 projects

Father, husband, C programmer, and Linux apologist. Think before you code.

#11386 The Future of C++
2 months ago

I rarely use C++. C's simplicity is what drew me to it in the first place, and that is what I would like to see in C++ for me to be more excited to switch.

C++ needs more things to be removed, not added. Now, I do think C++ has lots of value added on top of what C already provides. What would make it better would be to have a committee that decided to drill down on the core of the language, remove everything else, and focus on making the core rock solid before ever adding more "features."

Build a man a fire, he'll be warm for a day.
Set a man on fire, he'll be warm for the rest of his life.
godratio
Ray Garner
27 posts
#11389 The Future of C++
2 months ago

Make it so -> and the . do the same thing. They are redundant.
mmozeiko
Mārtiņš Možeiko
1315 posts
1 project
#11390 The Future of C++
2 months ago Edited by Mārtiņš Možeiko on March 20, 2017, 5:09 a.m.

They are not redundant in C++. In C it makes sense to get rid of them, but not in C++. In C++ -> and . are very different things. Why? You can overload -> Overloading . doesn't make much sense, because then you'll loose ability to access object members.

I would really like C++ to support C99 designated initializers. They are so useful.
Computed goto in standard also would be nice.
ratchetfreak
262 posts
#11391 The Future of C++
2 months ago

The 2 features discussed for C++17 I think will impact the language the most are concepts and modules. IMO both will fix big issues with the language as it stands (if properly specified...).

Concepts will help a lot with debugging templates especially when they include declaration-time checking of templates to ensure that when the template is declared to use a concept it only uses things that the concept actually has.

Modules will fix the header semantics (but be separate from them so existing semantics are preserved...) so that precompilation of the module will be possible and expected.
Jesse
34 posts
#11396 The Future of C++
2 months ago Edited by Jesse on March 20, 2017, 4:39 p.m.

mmozeiko:
I would really like C++ to support C99 designated initializers. They are so useful.
Computed goto in standard also would be nice.


This. Java has a form of computed goto, and it makes deeply nested conditionals inside loops less obnoxious. You can fake this in C but having a goto go to a no op, but that's hacky.

Clang++ supports C99 d.i as an extension, btw.
mmozeiko
Mārtiņš Možeiko
1315 posts
1 project
#11401 The Future of C++
2 months ago Edited by Mārtiņš Možeiko on March 20, 2017, 7:03 p.m.

Sure, gcc also does. But MSVC doesn't :( I waited for designated initializers in MSVC for a long time, and once MSVC 2013 started to support it, I was started to use them everywhere in my C code. But I want that also in C++ :)
MandleBro
Jack Mott
96 posts
1 project

Web Developer by day, game hobbyist by night. Fond of C and F#

#11402 The Future of C++
2 months ago

Some fever dreams I have:

Something like Standard ML/OCaml with .NET style generics, compiled native and no GC. Rust is actually somewhat like this. Maybe I should just use Rust. They add a lot of extra verbosity to ML which is too bad but not the worst thing in the world.


No more JITs. Everything should have an option to compile native before it ships. Then the Javas and C#s out there could do more aggressive optimizations and we wouldn't have to distribute run times with our programs or waste cycles compiling code every time we run.


BUT IF WE DO JIT - Any language that JITs should include a library where you can express vectorized operations and the JIT will runtime determine what SIMD instructions are available and produce good code for it. .NET does this now with a limited subset of SIMD operations. It is really cool when it has the operations you need, but that is rarely the case. With complete coverage of SIMD instructions it would be amazing. CPU clock cycles aren't improve much but SIMD width has gone from 128 to 256 and now 512 bits in the last 10 years. Free speed that only C++ programmers can use well and only with great effort.




John_Uskglass
Laurie
28 posts
#11409 The Future of C++
2 months ago

Jeremiah:
C++ needs more things to be removed, not added.

Simplicity is great to have, but it's super hard to claw back. The committee seems to have been trying to remove old deprecated stuff, but it's really hard when you know you'll be breaking someone's code.

Ray Garner:
Make it so -> and the . do the same thing.

Yeah this one is annoying. Doesn't help that Visual Studio always seems to auto-correct from the right one to the wrong one too ;). Maybe I'm just unlucky with that.

Mārtiņš Možeiko:
support C99 designated initializers

Yeah this would be great. Thinking of things C has that C++ doesn't, how about a standardised restrict keyword for C++?

ratchetfreak:
The 2 features discussed for C++17 I think will impact the language the most are concepts and modules.

Yeah these will definitely be big changes, although sadly neither seems to have made it into C++17. I think VC++ 2017 has some modules support though, and GCC 6 has some concepts support, so maybe we'll be able to start using them in practise before they get officially welcomed into the standard.

Jack Mott:
Something like Standard ML/OCaml with .NET style generics

I don't have any experience with either of these. Could you tell me what kind of things they offer? In the context of C++, are they something that the template system could be extended to do, or are they completely different?

So here's another aspect of this I think is interesting. What are your thoughts on small vs large changes to the language? For example, C++11 introduced some pretty massive changes, whilst C++17 feels a lot more like a "quality of life" update. Personally, I quite appreciate the small bits of syntactic sugar that have been added (e.g. pattern matching, optional etc.) which just make everyday programming a little more pleasant. On the other hand, these things could just be seen as adding complexity to the language, and as procrastinating whilst not dealing with the larger issues. What are your thoughts?

Also is anyone else following the work of SG14? Any thoughts on any of their proposals like flat containers, colonies, likely/unlikely, lightweight exceptions etc.?
novus1044
9 posts
#11416 The Future of C++
2 months ago

I agree that C++ needs more of an overhaul rather than anything else. In some places the language is far too verbose while other times it is far too terse.

I think this is why languages like JAI/Odin/Rust have potential because they can take the useful aspects of a language like C++ and put it into a more cohesive package. Although I included Rust, I think they went a bit too far on the safety angle.

There is some seriously good work being done with Odin and JAI and hopefully they both gain traction as alternatives to C/C++. I wish C++ could evolve into a language I would enjoy using, but I frankly think we are waaay past that point.

Just to note, I think C++ is a good language for its intended audience. It just isn't for me.
MandleBro
Jack Mott
96 posts
1 project

Web Developer by day, game hobbyist by night. Fond of C and F#

#11417 The Future of C++
2 months ago

It was just fever dreams =)
While I suppose you could add ADTs and pattern matching and Ifs as expression to c++ to make it StandradML-ish, the last thing C++ needs is more things.

And you would have to break backwards compatibility to convert templates to be more like .NET generics. Which, are just generally much easier to work with, and I don't think they support some of the crazy meta programming people do with templates.
Marthog
5 posts

None

#11452 The Future of C++
2 months ago Edited by on March 25, 2017, 11:15 a.m.

I like the modern C++ programming model a lot and I think, that the new features benefit it a lot.
Unfortunatly C++ is often too verbose and the many features interact in very weird ways and create many edge cases, that you have to be aware of.

Rust does a great job at taking the core ideas of modern C++ and putting them into a much simpler language.


John_Uskglass:

Jack Mott:
Something like Standard ML/OCaml with .NET style generics

I don't have any experience with either of these. Could you tell me what kind of things they offer? In the context of C++, are they something that the template system could be extended to do, or are they completely different?


They have a similar use, but are internally fundamentally different.

templates are more a macro system. They first expand and then typecheck. The problem is, that type errors somewhere deep in the call chain are quite verbose and hard to understand. Therefore template-heavy code looks nice on the call side, but is often hard to develop.

ML-inspired type systems typecheck first. When you call a generic function, it is already typechecked internally and you only need to match the signature on the call side.

It is not possible, to build the ML-type system on top of templates, but concepts at least get rid of the problematic error messages for the user.

None