The video actually makes it an important point that this is not the case since C and C++ are different languages with different design philosophies. However, in the areas where they overlap, it makes sense to eliminate silly differences (like 'func()' vs 'func(void)' or '= {};' vs '= {0};').
Auto and constexpr fix specific problems that also exist in C (auto is useful in type-agnostic macros, and constexpr finally fixes the problem that a const isn't actually a constant.
One interesting tidbit (which I didn't know yet) is that the C committee requires two real-world implementations for a proposal to even be considered (with the C++ standard counting as "implementation"), while the C++ committee doesn't require an implementation. Meaning C++ users are essentially guinea pigs for the C standard ;)
Explains why C++ has become such a hot mess, while C has been mostly spared any serious f*ckups (I can only think of one: VLAs, but those have essentially been removed from the standard in C11).
VLA were not removed. VLAs are almost always better than the next best alternative:
- They are better than alloca due to proper scoping and standard compliance.
- They use less stack than regular arrays on the stack with a worst-case size (e.g. a divide-and-conquer algorithm that may need O(N^2) stack space without VLAs could potentially be written using O(N log(N)))
- VLAs can allow more accurate bounds checking than with worst-case sized arrays.
- VLAs are faster than heap allocation.
There are issues with VLAs: If the size is controlled by an attacker, then this could cause security issues. This is largely mitigated by -fstack-clash-protection which transforms this into a DOS (same as unbounded heap allocation) and you want to have stack clash protection anyway. Static analysis tools and compiler flags can also help to detect cases where the size is controlled by input from the network. Assembler for VLAs worse than for fixed size array, but this goes at the cost of less space saving. But, again, people who avoid VLAs blindly because of these issues then often use something which is worse.
Also note that most other languages except C++ also have VLAs.
Most of the stuff it imported from C++ are relatively minor convenience things, not radical paradigm shifts. You make it sound like C23 started adding stuff like classes or templates.
I think it's more that unsafe/unpredictable pre-processor features are being implemented in the compiler so that more errors can be checked at compile time
flohofwoe|2 years ago
Auto and constexpr fix specific problems that also exist in C (auto is useful in type-agnostic macros, and constexpr finally fixes the problem that a const isn't actually a constant.
One interesting tidbit (which I didn't know yet) is that the C committee requires two real-world implementations for a proposal to even be considered (with the C++ standard counting as "implementation"), while the C++ committee doesn't require an implementation. Meaning C++ users are essentially guinea pigs for the C standard ;)
Explains why C++ has become such a hot mess, while C has been mostly spared any serious f*ckups (I can only think of one: VLAs, but those have essentially been removed from the standard in C11).
uecker|2 years ago
There are issues with VLAs: If the size is controlled by an attacker, then this could cause security issues. This is largely mitigated by -fstack-clash-protection which transforms this into a DOS (same as unbounded heap allocation) and you want to have stack clash protection anyway. Static analysis tools and compiler flags can also help to detect cases where the size is controlled by input from the network. Assembler for VLAs worse than for fixed size array, but this goes at the cost of less space saving. But, again, people who avoid VLAs blindly because of these issues then often use something which is worse.
Also note that most other languages except C++ also have VLAs.
ngcc_hk|2 years ago
arp242|2 years ago
ChrisRR|2 years ago