The most exciting news about C++ would not be added features, but removed features. That is what everyone in their heart is waiting for.
And everybody who doesn't do so really deserves the pain that results later on.
Such suppression are than big warning signs in the code telling you that something exceptional is going on which needs extra attention when touched.
Also warnings may be wrong. Errors mustn't be and can't be as strict as warnings therefore.
But it shouldn't be possible to "just ignore them". If you do, this needs to be done deliberately and explicitly.
But I see, you're not interested in correcting the bugs you produce. You obviously prefer the "three-monkeys solution" to correctness problems.
It's a good general practice, as long as exceptions can be made.
Some compiler warnings are rooted in the compiler being unable to prove something that is actually true.
I want good practices to be the thing people actually do!
I know this won't be applicable in many cases regarding C++ projects, but if you want to see state-of-the-art code gen features in action have a look at Scala 3:
https://docs.scala-lang.org/scala3/reference/metaprogramming...
With something like that in place you actually don't need any (runtime) reflection (which is also available on the JVM OOTB, just in case).
In contrast quotes and splices aren't reflection at all! The whole point about them is that they're "black box". You (usually) can't "extract information" form a quote in a safe way (so it's the exact contrary to reflection). That's still something academia is trying to solve (even there are some proposals out)¹.
Where can I learn more about the C++ proposals to compare?
---
¹ https://dl.acm.org/doi/10.1145/3136000.3136005
¹ https://dl.acm.org/doi/10.1145/3158101
And the recent work that underlines the solution included in Scala 3:
¹ https://se.informatik.uni-tuebingen.de/publications/stucki21...
I mean, that's just because many languages don't even have a compile-time so of course reflection can only be runtime. Every compiled language has at least some amount of extremely basic concept of compile-time reflection, e.g. sizeof in C for instance which yields a constant expression ; likewise, `if constexpr(std::is_same_v<T, some_other_type>) { ... }` which we can do since C++17 is very much in the domain of compile-time reflection.
Here's the most recent paper: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p12...
If you want this is a very good read: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p07...
Finally, there is an implementation of the reflection TS: https://clementpirelli.wordpress.com/2021/12/08/cpp-reflecti...
It's not always easy to find the relevant stuff in C++ land.
Thanks a lot!
I have to read this stuff first, but my gut feeling would still be that `constexpr` and such isn't reflection at all.
The `sizeof` example seems more in this direction (because some expression gets actually inspected).
e.g.
void f(auto x) {
// common code path
if constexpr(x is floating-point) {
// code path 1
}
else if constexpr(x is a string) {
// code path 2
}
// common code path
}Thanks for the pointer.
Nope. Not waiting for that. Does not mean I am using or ever will every feature. However if it exists and being used by others I have nothing against it.
But indeed, these things can't be removed or reworked without breaking backwards compatibility. (And if you seriously take on reworking them, you'll end up with a different language, which we already have several.)
... huh? i'm fairly confident dereferencing void is not valid C++ ; at the very least gcc/clang/msvc do not compile it: https://gcc.godbolt.org/z/hK6qb1z6o
s/no one/I/I am just worried that some proponents of "move fast and break things" might be undervaluing what they are breaking, although C++ committees are are generally good about backward compatibility.
If the only side effect of breaking backwards compatibility is making the people that write C++ as if it was C89 irritated and upset, then that's probably a good thing, let's do it more.
C++11 is 11 years old. If you haven't modernized your code base in 11 years you never will.
If you are using ancient C++, compiler security updates are the least of your security concerns.
If you have code that nobody understands and cannot be touched, you should see that as the real problem and an urgent call to action to fix it, not modernization.
That doesn't make it a dead codebase. New code still gets written - and it helps when it can be written using newer, better techniques while working nicely with old code. I once worked on a codebase that had ancient code from mid-90s with explicit COM AddRef/Release side by side with C++11 lambdas and TMP.
Sounds like pure joy.
OTOH if we tried to rewrite the whole thing from scratch, we wouldn't ship a new feature for many years - only new bugs.
For example, if you port numeric libraries are you sure you maintain the same guarantees for numerical stability? If you are porting containers, do your new backing-array growth strategies achieve the same efficiency as using realloc? Do your new threading primitives have equivalent efficiency on all of the target architectures?
I would prefer to have warnings, or even errors, for 'known bad behaviour' that are enabled by default with new standards - think along the lines of `-fpermissive`. Forcing people to suppress these means that the onus is on them to accept the risks their choices bring.
However, just as with things like void*, the new standards are bringing in their own footguns. Ranges have pointer semantics, not value semantics, for example, which is totally non-obvious and actually means a lot of use cases for ranges just aren't possible. Newer isn't necessarily better, the people writing the original standards were brilliant as well and had their own insights which we now forget.
But your test suite would catch any issues, wouldn't it?
You have an exhaustive test suite for your important numeric libraries, right?
> If you are porting containers, do your new backing-array growth strategies achieve the same efficiency as using realloc? Do your new threading primitives have equivalent efficiency on all of the target architectures?
The benchmarks suite, which is part of your exhaustive test suite, and is guarding against performance regressions would catch any issues for sure!
You have a benchmarks suite to protect against performance degradation, right?
> You have a benchmarks suite to protect against performance degradation, right?
In theory, in a perfect world, yes.
In practice, people use open source libraries like Eigen because they are the best, not because of their extensive test coverage. Doing things which might break these libraries will fork the community.
Only because something spits out numbers really fast doesn't say anything about the quality of this something. Especially when considering that optimizing for speed comes most times with very hacky code! This, plus the fact that this code is usually written by laymen (scientist aren't software engineers!) makes such things very questionable.
After looking into scientific computing and the usual software "quality" there I lost quite some trust in anything that comes out of there. This was actually very disillusionary and extremely sad to find out. This could even destroy the broader trust in science in general (as everything today in this field depends on statistics calculated by computers). This would be an catastrophic outcome! But most people would currently even deny the existence of an issue…
Related (together with the parent): https://news.ycombinator.com/item?id=34224186
Also related as people (scientists!) got blinded by the promise of speed without considering correctness:
A house of cards… :-(
This is why subtle compiler rule changes are so potentially devastating.
It seems you know better than the C++ standard committee and Bjarne Stroustrup anyways.
And yes, you shouldn't use realloc... but what should you do if your buffer size is more than half of your physical memory?