It might be silly if you're working on your own. Software that delivers a lot of value is usually developed and evolved not only by team, but by a team with changing members and changing leadership over the project's lifetime. The features used will be the union of all features used over the years, and while it's easy for team leads to allow the use of more features than their predecessors, it's quite hard to reduce them.
Also, you may be forced to use language features you don't want if they're used by libraries whose functionality you do want. For example, when doing low-level programming, I don't like implicit calls that I can't clearly see on the page (e.g. destructors or overloaded operators). But if libraries I want use them, then I'll have those implicit calls. But if the language doesn't have those features, libraries obviously won't use them.
That's exactly the case when it's easiest. If you don't need a feature, just don't use it and case closed. With a team it's harder - you have to force/enforce others not to use a given feature.
> if they're used by libraries whose functionality you do want
If you're using C++ you can just use the C library you would've used otherwise, no?
Surprisingly, this is not true. I've written a C++ file only to realize at the end that I did not use any C++ features. Renaming the file to .c halved the compilation time.
As for the header thing, that'd could potentially be true if the compile time was something like 450ms -> 220ms, but why bother saying it when you're only saving a few hundred milliseconds
After writing that, I wrote my own standard library (it has data structs like vector, hashmap and sets; slices, strings, rng, print, some io functions, and more) which uses a lot of templates, and it compiles in <200ms on both clang and gcc. Many standard library headers take much longer to compile than that. It's not a terrible idea to have your own standard lib if you need quick compile times.
It's arguably irrational to evaluate a language based on this, but you can think of "this code could be better" as a sort of mild distraction. C++ is chock full of this kind of distraction.
The main difference from choosing a different subset, e.g. “Google C++” (i.e. writing C++ according to the Google style guide), is that the compiler enforces that you stick to the subset.
Oh, and smart pointers too.
And hash maps.
Vectors too while we're at it.
I think that's it.
And it wasn't hard to achieve. The idea was to use length delimited strings rather than 0 terminated. This meant that slices of strings being strings is a superpower. No more did one have to constantly allocate memory for a slice, and then keep track of that memory.
Length-delimited also super speeded string manipulation. One no longer had to scan a string to find its length. This is a big deal for memory caching.
Static strings are length delimited too, but also have a 0 at the end, which makes it easy to pass string literals to C functions like printf. And, of course, you can append a 0 to a string anytime.
One of the fun things about Empire is one isn't out to save humanity, but to conquer! Hahahaha.
BTW, one of my friends is using ClodCode to generate an Empire clone by feeding it the manual. Lots of fun!
The latter two (hash maps and vectors), though, are just compound data types that can be built on top of standard C. All it would need is to agree on a new common library, more modern than the one designed in the 70s.
Hash maps are mostly only important because everyone ought to standardize on a way of hashing keys.
But I suppose they can both be “bring your own”… to me it’s more that these types are so fundamental and so “table stakes” that having one base implementation of them guaranteed by the language’s standard lib is important.
A reason I can think of to not move to C++ is that it is a vast language and, if you are working on a team, it can be easy for team members ultimately forcing the whole team to become an expert in C++ simply because they all will be familiar with a different set of C++ features.
But for a solo dev? No reason not to use it, IMO. It's got a much nicer standard library with a rich set of datastructures that just make it easier to write correct code even if you keep a C style for everything.
A lot of smart people pick and choose what they want from the language, just like religion, they keep the good parts and discard the bad.
Even with the recent extension where it looks like it isn't, the compiler adds one for you.
I have a "mini-std" headerfile that's about 500 LoC implementing lightweight variants of std::vector, std::function, a stack-local std::function (unsafe as hell and useful as hell to avoid allocations), a shared-ptr, qsort and some other nifty stuff.
That does a lot of things, but even then I use other patterns that brings a lot of bang for the buck without having to go full C (hint: the stack-local function equivalent gets a lot of mileage).
int a = 3;
foo(a);
// What value has a ?
#define foo(a) a = 12On top of likely having worse performance.
Mindread much?
I feel like if you need to implement modern language features, you shouldn't be using C. The entire point of C is to not be modern.