3 ms·

> This static analyzer causes programmers to use 2 extra characters when using smart pointers, -> vs (*)., since the overloaded -> operator returns a pointer.

> This static analyzer causes programmers to use 2 extra characters when using smart pointers, -> vs (*)., since the overloaded -> operator returns a pointer. This renders it completely impractical -- sorry. You need to figure out a way to make it work, otherwise this is, errrm, useless. And what is 'this' static analyzer anyway. I thought this is about a language extension introducing possible general static analyzers. Is this a concrete one now? Or why do you already know that it cannot handle '->'? Did I miss something? What is this?

amluto 4y ago
It’s worse than useless. This guideline says that one should not write code in the straightforward, idiomatic way, and should instead write ugly code. If the language spec is such that operator -> can’t have a sensible signature, then FIX IT. Or teach the analyzer to recognize the idiomatic use. (And the * approach still eventually sticks a raw pointer into this.) I think this one is problematic too: > Using the union keyword produces an error. … It was replaced by std::variant, which is safer. Union is horribly unsafe, but at least union identifies its fields by name. Variant identifies its fields by position (unergonomic, error prone, and horrible for refactoring) or by type (unpleasant or useless when the type has no name or an unstable name, and even worse when two choices have the same type). C++ needs an actual sum type, and variant isn’t it. Sorry.
- kllrnohj 4y ago
  > C++ needs an actual sum type, and variant isn’t it. Sorry. Don't disagree at all, but in the meantime I'd still avoid union and use variant instead but wrapped in a class that exposes named accessors. You don't have to actually expose the orderings of a variant to anything that way. It's a bunch of annoying boilerplate to be sure, though. If the metaclasses proposal ever happens then it could be generated which would be cool.
  - amluto 4y ago
    This is yet another step on the slippery slope toward extremely slow compilation. I once timed this little program: #include <boost/variant.hpp> on a machine that was very fast for its time. It took seven seconds to compile! Now modern variadic templates are quite an improvement, but not enough of one. A metaclass generating an instantiation of an n-element variant which, in turn, instantiates the n-1 element tail, etc is quite a log of generated code and types, and anything using it needs to contend with all that complexity to resolve method calls, etc. In contrast, any language with native sum types can handle this efficiently. Furthermore, native sum types make it obvious to the compiler, type checker, static analyzers, etc that the type in question is actually a sum type. Getting a compiler to understand a metaclass-based variant well enough to do something like Rust’s sentinel value optimizations sounds miserable.
- simplotek 4y ago
  > If the language spec is such that operator -> can’t have a sensible signature, (...) The language spec has zero to do with this. You're commenting on a discussion on static code analyzers. The specific gotcha you're commenting on mentions that the overloaded operator -> from smart pointers returns a raw pointer to the object being managed, which apparently causes static code analyzers to lose context (it's a raw pointer). The gotcha just mentions a way to help out static code analyzers to not lose context. There's nothing wrong with the spec. At most there's a tip to help out current static code analyzers keep track of semantics. The worst part of people criticizing C++ is that 9 times out of 10 they base their criticism on ignorance or misconceptions.
  - amluto 4y ago
    The OP is literally a proposal to standardize modern and “safer” programming guidelines. The chain of logic comes from “Use lvalue references”, which claims that pointer are obsolete and programmers can avoid using them in most cases, other than narrow exceptions for strings, function pointers and such. But it proposes requiring a poor practice of avoiding operator ->. There are two obvious solutions here: either improve the proposal to make an exception for -> or improve the language so that -> is friendlier for static analyzers.

amluto 4y ago

It’s worse than useless. This guideline says that one should not write code in the straightforward, idiomatic way, and should instead write ugly code. If the language spec is such that operator -> can’t have a sensible signature, then FIX IT. Or teach the analyzer to recognize the idiomatic use. (And the * approach still eventually sticks a raw pointer into this.) I think this one is problematic too: > Using the union keyword produces an error. … It was replaced by std::variant, which is safer. Union is horribly unsafe, but at least union identifies its fields by name. Variant identifies its fields by position (unergonomic, error prone, and horrible for refactoring) or by type (unpleasant or useless when the type has no name or an unstable name, and even worse when two choices have the same type). C++ needs an actual sum type, and variant isn’t it. Sorry.

kllrnohj 4y ago
> C++ needs an actual sum type, and variant isn’t it. Sorry. Don't disagree at all, but in the meantime I'd still avoid union and use variant instead but wrapped in a class that exposes named accessors. You don't have to actually expose the orderings of a variant to anything that way. It's a bunch of annoying boilerplate to be sure, though. If the metaclasses proposal ever happens then it could be generated which would be cool.
- amluto 4y ago
  This is yet another step on the slippery slope toward extremely slow compilation. I once timed this little program: #include <boost/variant.hpp> on a machine that was very fast for its time. It took seven seconds to compile! Now modern variadic templates are quite an improvement, but not enough of one. A metaclass generating an instantiation of an n-element variant which, in turn, instantiates the n-1 element tail, etc is quite a log of generated code and types, and anything using it needs to contend with all that complexity to resolve method calls, etc. In contrast, any language with native sum types can handle this efficiently. Furthermore, native sum types make it obvious to the compiler, type checker, static analyzers, etc that the type in question is actually a sum type. Getting a compiler to understand a metaclass-based variant well enough to do something like Rust’s sentinel value optimizations sounds miserable.
simplotek 4y ago
> If the language spec is such that operator -> can’t have a sensible signature, (...) The language spec has zero to do with this. You're commenting on a discussion on static code analyzers. The specific gotcha you're commenting on mentions that the overloaded operator -> from smart pointers returns a raw pointer to the object being managed, which apparently causes static code analyzers to lose context (it's a raw pointer). The gotcha just mentions a way to help out static code analyzers to not lose context. There's nothing wrong with the spec. At most there's a tip to help out current static code analyzers keep track of semantics. The worst part of people criticizing C++ is that 9 times out of 10 they base their criticism on ignorance or misconceptions.
- amluto 4y ago
  The OP is literally a proposal to standardize modern and “safer” programming guidelines. The chain of logic comes from “Use lvalue references”, which claims that pointer are obsolete and programmers can avoid using them in most cases, other than narrow exceptions for strings, function pointers and such. But it proposes requiring a poor practice of avoiding operator ->. There are two obvious solutions here: either improve the proposal to make an exception for -> or improve the language so that -> is friendlier for static analyzers.