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!
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!
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."
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."
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.
I would really like C++ to support C99 designated initializers. They are so useful.
Computed goto in standard also would be nice.
Edited by Mārtiņš Možeiko
on
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.
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.
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.
Edited by Jesse
on
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++ :)
Edited by Mārtiņš Možeiko
on
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.
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.
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.?
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.
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.
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.
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.
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.
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.
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.
Edited by Marthog
on