Anyone else getting concerned about the rate of development of the C++ Standard vs compiler implementation? We don't even have feature complete C++20 on the major compilers yet. C++23 is even less implemented. How will the committee handle this? Will they reduce feature additions at some point in the future?<p><a href="https://en.cppreference.com/w/cpp/compiler_support" rel="nofollow">https://en.cppreference.com/w/cpp/compiler_support</a>
I always like these new comile time features getting into the C++ spec.<p>I'm actually looking forward to the related reflection features that I think are currently in scope for C++26. I've run into a number of places where the combination of reflection and constexpr could be really valuable... the current workarounds often involving macros, runtime tricks, or both.
Recent C++ changes seem like polishing your firewood before burning it. Yes, they make perfect sense, but often they are a fix to a problem that committee introduced by cutting down previous proposals (e.g. forcing lambdas to be single return statement, then relaxing it).<p>Half of new features feel like "how to make STL implementation less embarassing".<p>Meanwhile there still is no language support for e.g. debugging constexpr, or printing internal private state of objects in 3rd party code.
That’s super cool; c++ is always the sharpest tool in the drawer (and by virtue the funnest!)..<p>It’s too bad you still can’t cast a char to a uint8_t though in a constexpr expression.
every release adding more constexpr stuff honestly helps me - been burned by old template hacks enough lol. you think we ever get to a real point where all this new power just makes stuff easier, or is it always tradeoffs?
Are they flogging a dead horse?<p>C++ is, should be, like COBOL. A very important language because of the installed base. But why the continual enhancements? Surely there are better uses of all those resources?