You think that's bad? I saw people complaining that C23 removed K&R functions, and those have been deprecated since the original C89 standard. If thirty-four years isn't enough time to remove a deprecated feature, then there never will be enough time for it.
if you are in the field of "has to work, _guaranteed_ " and you _need_ a chain of _verified correct_ software, guess what: you go back to a subset of C99 (subset because a few things are missing). There is no verified C++ compiler. I mean... okay, _technically_ if you make a C++-to-C compiler, you're ok?
@@Nobody1707when is it easier to remove mould? A few days after it appears, or a few decades after it appears? People make the mistake thinking that giving others _a lot of time_ is a good idea. No. It is a very, _very_ bad idea. You give them the least time possible. Consider Apple. Much as I hate them, they transitioned from powerpc to intel to arm in _less than two decades_ . Meanwhile, AMD64 has been around for just as long and yet _we're still carrying along the ball and chain that is x86_ . FFFFFFFFFF x|
Am I the only one that hates trailing return types? I get that some people think the few tiny examples where the standard restricts you and tries to claim that's the only way to solve the issue are somehow worth the annoyance, but that's just a failure of compiler authors and their negative influence on the committee. I'm really starting to feel like every good decision they made was countered with two bad ones. And I'm sure someone will claim the opposite method is annoying, like having enclosing class inference on the return type is impossible if the compiler has to look forward to the function name and its resolved namespace, but I've not found that to be an issue at all in my own compiler.
For me it's very pragmatic. By the time I have [[nodiscard]] constexpr blah blah blah, the return type gets lost, so I move it to the end of the function declaration.
@@cppweekly That at least makes some semblance of sense. But I would just do away with a lot of the attributes too. Most of those keywords are just about optimization hints anyway, and I remain unconvinced that the compiler needs help in most of those cases.
Is there simple examples (for dummies), how you can compile others github project? Or is difficulty that, project have not build using Visual Studio at all...
p*thon, because there weren't enough scripting languages out there and most importantly, there was no scripting language out there that could be considered downright disastrous 🤮
It's sad that moving from a 13 year old version of the language to a 10 year old version is still a hurdle for many companies....
Dude, *I'm* the company and at times I'm too scared to change/modernize my stuff and risk introducing regression bugs...🤐
You think that's bad? I saw people complaining that C23 removed K&R functions, and those have been deprecated since the original C89 standard. If thirty-four years isn't enough time to remove a deprecated feature, then there never will be enough time for it.
if you are in the field of "has to work, _guaranteed_ " and you _need_ a chain of _verified correct_ software, guess what: you go back to a subset of C99 (subset because a few things are missing). There is no verified C++ compiler. I mean... okay, _technically_ if you make a C++-to-C compiler, you're ok?
@@Nobody1707when is it easier to remove mould? A few days after it appears, or a few decades after it appears? People make the mistake thinking that giving others _a lot of time_ is a good idea. No. It is a very, _very_ bad idea. You give them the least time possible. Consider Apple. Much as I hate them, they transitioned from powerpc to intel to arm in _less than two decades_ . Meanwhile, AMD64 has been around for just as long and yet _we're still carrying along the ball and chain that is x86_ . FFFFFFFFFF x|
Am I the only one that hates trailing return types? I get that some people think the few tiny examples where the standard restricts you and tries to claim that's the only way to solve the issue are somehow worth the annoyance, but that's just a failure of compiler authors and their negative influence on the committee. I'm really starting to feel like every good decision they made was countered with two bad ones. And I'm sure someone will claim the opposite method is annoying, like having enclosing class inference on the return type is impossible if the compiler has to look forward to the function name and its resolved namespace, but I've not found that to be an issue at all in my own compiler.
... what do you mean "in my own compiler"? You sound scary
@@GeorgeTsiros It's scary to write your own compiler?
@@anon_y_moussefor c++? YES, YES IT IS.
For me it's very pragmatic.
By the time I have [[nodiscard]] constexpr blah blah blah, the return type gets lost, so I move it to the end of the function declaration.
@@cppweekly That at least makes some semblance of sense. But I would just do away with a lot of the attributes too. Most of those keywords are just about optimization hints anyway, and I remain unconvinced that the compiler needs help in most of those cases.
Is there simple examples (for dummies), how you can compile others github project?
Or is difficulty that, project have not build using Visual Studio at all...
Well, depending on the project, it's going to use different build system, so you will have to be more specific
If people want you to build their project they should provide a readme with instructions.
Where can one find the source code?
github.com/cpp-best-practices/infiz
@@cppweeklyThank you so much!
p*thon, because there weren't enough scripting languages out there and most importantly, there was no scripting language out there that could be considered downright disastrous 🤮