3 ms·

> Mentioned statically typed languages C,C++ and Java are pretty old and therefore carry some baggage of verbosity that is no longer needed. hahaha. Just gett

> Mentioned statically typed languages C,C++ and Java are pretty old and therefore carry some baggage of verbosity that is no longer needed. hahaha. Just getting people to adopt `auto` in C++ is an uphill battle. People want to write types.

lasagnaphil 8y ago
Sometimes writing out the types make the code clearer (while auto is good for long type names like std::vector::iterator). And although this is an edge case, if you use template-expression libraries like Eigen, you are forbidden to use auto (otherwise the template deductions don’t work properly)
- vnorilo 8y ago
  I'm curious of when this would actually happen. Some kind of recursive implicit specialization? AFAIK auto x=foo; is just sugar for decltype(foo) x=foo; rather than MLish inference.
  - jcelerier 8y ago
    The problem with the technique used by Eigen (and also Boost.Spirit among a few other famous libs), called expression templates, is that it leverages the fact that the references to temporaries in function calls will be maintained until the end of the expression. The last operation in the expression (assignment to a specific type) will do processing to preserve those temporaries, compute the result, etc... e.g. it more or less looks like this in a trivial case : #include <cstdio> template<typename T1, typename T2> struct add { add(const T1& t1, const T2& t2): lhs{t1}, rhs{t2} { } const T1& lhs; const T2& rhs; constexpr auto get() const { return lhs.get() + rhs.get(); } }; struct integer { const int& i; constexpr const int& get() const { return i; } }; int f(); int main() { auto x = add{add{integer{f()}, integer{f()}}, add{integer{f()}, integer{f()}}}; } Here, storing the value in `auto` is wrong because by the time the expression has ended, the references point to stuff that isn't in scope anymore Hence the solution is to introduce a type that will actually do the computation or store the result during the expression ; but before C++11 you had to introduce a type here anyways, which is what was done and of course it worked.
toast0 8y ago
I've basically spent my career without static types (except for the little bits of C that happen here and there), but I keep hearing about how types would change my world ... But then evertime I've looked at a typed language lately, everything is type 'auto'. Well, maybe not Java, I don't think they have auto yet? As an honest question, if types are good, why would you put auto, instead of telling me the type? For context, I'm a neanderthal and just use a boring text editor, so I'm not getting any tool assisted type information if you write auto everywhere.
- jayd16 8y ago
  As others have said, you keep all the static checking with these systems but you get the brevity of a shorter definition. It also makes refactoring easier. If you use var then you don't need to change all your declarations if you change a class name.
- pjmlp 8y ago
  Because even with type inference, the compiler shouts at me during compile time if they don't match, instead of crashing at runtime, because Joe of the 5th floor forgot to add a field when he checked in his code. So I don't need to write additional unit tests to do the compiler's work that would have prevented Joe to check in his code.
- cube2222 8y ago
  Because it's quicker to write and often more readable. Your IDE (or tooling) can provide you with the type of a variable whenever you want.
- IshKebab 8y ago
  Automatic type deduction is not the same as dynamic typing. There are still types and you still get compile time errors if they don't match.
pjmlp 8y ago
Not only in C++, everywhere. It is incredible the FUD in C# and Java against var, you see endless threads of how they are now dynamically typed like JavaScript. Sometimes I wonder how did those ended up learning to program, don't people read books any more?!
- jcelerier 8y ago
  yep, only did a few C# projects but had the same experience.
Asooka 8y ago
The general rule of thumb for us is "auto is allowed if the type is written on the line somewhere, or if you're writing a for-each of a container, where it has to be const auto &, unless you have good justification for the copies". The inadvertent copies in for-each constructs are the biggest pitfall for us, because let's just say you don't pick C++ to write software that doesn't have to be as fast as possible :) .

lasagnaphil 8y ago

Sometimes writing out the types make the code clearer (while auto is good for long type names like std::vector::iterator). And although this is an edge case, if you use template-expression libraries like Eigen, you are forbidden to use auto (otherwise the template deductions don’t work properly)

vnorilo 8y ago
I'm curious of when this would actually happen. Some kind of recursive implicit specialization? AFAIK auto x=foo; is just sugar for decltype(foo) x=foo; rather than MLish inference.
- jcelerier 8y ago
  The problem with the technique used by Eigen (and also Boost.Spirit among a few other famous libs), called expression templates, is that it leverages the fact that the references to temporaries in function calls will be maintained until the end of the expression. The last operation in the expression (assignment to a specific type) will do processing to preserve those temporaries, compute the result, etc... e.g. it more or less looks like this in a trivial case : #include <cstdio> template<typename T1, typename T2> struct add { add(const T1& t1, const T2& t2): lhs{t1}, rhs{t2} { } const T1& lhs; const T2& rhs; constexpr auto get() const { return lhs.get() + rhs.get(); } }; struct integer { const int& i; constexpr const int& get() const { return i; } }; int f(); int main() { auto x = add{add{integer{f()}, integer{f()}}, add{integer{f()}, integer{f()}}}; } Here, storing the value in `auto` is wrong because by the time the expression has ended, the references point to stuff that isn't in scope anymore Hence the solution is to introduce a type that will actually do the computation or store the result during the expression ; but before C++11 you had to introduce a type here anyways, which is what was done and of course it worked.

toast0 8y ago

I've basically spent my career without static types (except for the little bits of C that happen here and there), but I keep hearing about how types would change my world ... But then evertime I've looked at a typed language lately, everything is type 'auto'. Well, maybe not Java, I don't think they have auto yet? As an honest question, if types are good, why would you put auto, instead of telling me the type? For context, I'm a neanderthal and just use a boring text editor, so I'm not getting any tool assisted type information if you write auto everywhere.

jayd16 8y ago
As others have said, you keep all the static checking with these systems but you get the brevity of a shorter definition. It also makes refactoring easier. If you use var then you don't need to change all your declarations if you change a class name.
pjmlp 8y ago
Because even with type inference, the compiler shouts at me during compile time if they don't match, instead of crashing at runtime, because Joe of the 5th floor forgot to add a field when he checked in his code. So I don't need to write additional unit tests to do the compiler's work that would have prevented Joe to check in his code.
cube2222 8y ago
Because it's quicker to write and often more readable. Your IDE (or tooling) can provide you with the type of a variable whenever you want.
IshKebab 8y ago
Automatic type deduction is not the same as dynamic typing. There are still types and you still get compile time errors if they don't match.

pjmlp 8y ago

Not only in C++, everywhere. It is incredible the FUD in C# and Java against var, you see endless threads of how they are now dynamically typed like JavaScript. Sometimes I wonder how did those ended up learning to program, don't people read books any more?!

jcelerier 8y ago
yep, only did a few C# projects but had the same experience.

Asooka 8y ago

The general rule of thumb for us is "auto is allowed if the type is written on the line somewhere, or if you're writing a for-each of a container, where it has to be const auto &, unless you have good justification for the copies". The inadvertent copies in for-each constructs are the biggest pitfall for us, because let's just say you don't pick C++ to write software that doesn't have to be as fast as possible :) .