4 ms·
Wow, thank you for this rich and thorough follow up. Interestingly, in the present C++ standard, 'mutable' indeed is a storage class like 'register' while 'cons
by compiler-devel 4y ago
Wow, thank you for this rich and thorough follow up. Interestingly, in the present C++ standard, 'mutable' indeed is a storage class like 'register' while 'const' is a CV-qualifier. I thought it quite odd that 'mutable' isn't a CV-qualifier (the standard leaves this gap open) and for nonmember variables, my patch makes it a CV-qualifier; otherwise it remains a storage class specifier.
WRT lambda changes, I have no particular timeline for this project as it's something I took up on the side. Pointers kinda break any data flow analysis that could be done. For example, imagine an object that serializes itself in one translation unit and is deserialized in another using a different class (this is somewhat common in telecommunications code. Imagine a struct Header { ..., void end[0]; }; which is used to handle messages of variable length but with the same Header types).
Java does just fine without goto (or have they added that since 2010?).
I think code that is intentional is more effective than code that is accidental. That said, I'd rather suppress the unused parameter warning with the '#pragma diagnostic ignored' mechanism than use a cast mechanic that just happens to address a compiler issue.
Thank you for the great list of rules! I agree with them all. Minor nit: you can't use static_cast to cast away constness.
- dataflow 4y ago> Java does just fine without goto (or have they added that since 2010?). C++ is quite literally meant for use cases where Java (or Python or C# or Go or pretty much any other language) is not "just fine". And as I mentioned above, you CAN get by without goto. You just have to go through (go to?) contortions in certain cases without it that make the situation worse rather than better. (And there is no reason to believe such use cases are equally common across all languages, so keep that in mind. For example hardware contexts require dealing with explicit state machines a lot more than software contexts do, and C/C++ are used more in those contexts—to name just one example.) Remember Java was doing "just fine" without lambdas, and it's still doing "just fine" without templates, value types, manual memory management, and a million other things you find in C++. Even C was also doing "just fine" without generics and destructors, but then they realized they're missing out and finally added it. You have to realize, goto is basically a religion nowadays. People want to believe goto has no legitimate use cases, because (I can only assume) they're scared someone will use it as an excuse to utilize it irresponsibly outside those contexts. Kind of like why some drugs require prescriptions, I guess. I can't stop people from believing what they want, but as far as facts go, it does have use cases that many people simply don't encounter, and I tried to list some of them in my comments above. > Minor nit: you can't use static_cast to cast away constness. You actually can! Check this out: int const b = 1; int const *p = &b; **static_cast<int **>(static_cast<void *>(static_cast<int const **>(&p))) = 2; assert(p == &b && *p == 2); If this is surprising... I would take it as an indication that it's difficult to foresee what can be done even with the commonplace features in the language (in both good and bad directions), let alone the rare ones (like goto).
- compiler-devel 4y agoCan you cast away const with a single static_cast? Your static_cast chain is analogous to my example of serializing/deserializing across TUs because the memory is treated as a pointer to storage (your second static_cast<void*>). As I understand, the original question you asked pertained to using one of the C++ cast operators in place of a single C style cast.
- dataflow 4y agoOh shoot I'm sorry, I misunderstood your comment. Yeah you're right, the const_cast isn't important for casting away const, so it's not important for that rule as far as that goes, good point! This is why I also need to sit down and think about these before I can be confident in them :)