5 ms·

Do you allow this to pass code review (ignoring the bad name 'foo')? foo (Ax); 'A x' creates a temporary with no documented type, but the conceit here is

by RogerL 12y ago

Do you allow this to pass code review (ignoring the bad name 'foo')? foo (A*x); 'A * x' creates a temporary with no documented type, but the conceit here is that we don't care. They could be ints, floats, matrices - any data type that implements '*'. By and large that is fine. Here you are just moving x to y. What is the type of y? the same type as x, which supposedly didn't cause you heartache throughout the rest of the function. Stroustrup gave an interesting talk this year about how, everytime he introduced a new feature, people complained that it was not clear and asked for very verbose syntax. Instead of foo<T>, we get template<typename T> foo<T>(T, well, you get the idea. Now everyone is familar with templates and loath the verboseness. Back to auto, it allows for 'generic' programming. Do you object to templated functions? template<class T> T add (T a, T b) { return a + b; } That seems really clear to me, as is the auto version: auto add (auto a, auto b) { return a + b; } If that is clear, why is auto x = a + b; unclear? I can certainly come up with counterexamples where it isn't clear, but by and large I love auto, and use it all the time. (counterexample: we care about the type of x because we need to cast to a 16-bit int because it is going to be use to communicate with hardware).

plorkyeran 12y ago
> we care about the type of x because we need to cast to a 16-bit int because it is going to be use to communicate with hardware IMO you should still use auto there and use a static_cast<int16_t> on the RHS to make it clear to the reader that you're deliberately converting it.
- RogerL 12y ago
  You're right.
yongjik 12y ago
Problem arises when we find "y" deep in a function, searches for its definition, and encounters "auto y = std::move(x);". Now we have to know the type of x, and if x is defined similarly, up the chain. Not fun. foo(A * x) doesn't pose similar problem. On the other hand, if I write auto bar = foo(A*x); Then we can have the same problem (esp. if foo is a templated function).
- mpyne 12y ago
  > Problem arises when we find "y" deep in a function, searches for its definition, and encounters "auto y = std::move(x);". This is gun control applied to computer languages. The solution is not to ban a useful feature that would ordinarily aid the understandability of code, the solution is to not abuse such features to write gibberish. People can write spaghetti code with any syntax you provide them, even Python.
- RogerL 12y ago
  To be honest, I just hover my mouse over 'bar' to get the type, and I name 'bar' something more meaningful than bar. "ball_covariance", "movie_recommendations", or whatever that matrix multiplication is computing for me. I wrung my hands when I started using 'auto' but none of the worries came to pass. But yes, if the code is unreadable without a type, add a type. No biggie, and no one is suggesting inflexible application of rules (always use 'auto' if it is possible). The same way when I might call foo(boo(x)); and it is not clear, I'll explicitly name the output of boo in a temporary variable: auto robot_velocity = boo(x); auto robot_covariance = foo(robot_velocity); And if that ain't enough, then sure, do this: robot::vector<float> robot_velocity = boo(x); robot::matrix<float,float> robot_covariance = foo(robot_velocity); I have to say, I find the last the most unreadable. I almost never care deeply about the type, and care deeply about the meaning. Interestingly, no one worries about typedef. typedefs wrapped around intricate collections (map of lists of dictionary of arrays) can effectively obscure what the underlying types are just as much as auto. But again, mouse hover, CTRL+I, or whatever your IDE supplies pretty much makes that a non-issue as well. edit: the problem you are describing is due to too big a function, not 'auto'.
- stinos 12y ago
  when we find "y" deep in a function There should be no such thing as deep in a function, or at least not as deep as you mean (i.e. so deep that you can't figure out what y is): that would in all likelyhood mean your function is too long, has too much responsabilities. Good functions are short and composed of other short functions, they should be short enough so that you can read them through without ever having to wonder 'wtf is this?' I know this might sound like textbook stuff without practical use but it's simply the truth, as I learned through the years. In those years my functions only became shorter, and hence better named, and more reusable, and all code simpler to read. So auto was a godsend that didn't hurt once.

Do you allow this to pass code review (ignoring the bad name 'foo')? foo (A*x); 'A * x' creates a temporary with no documented type, but the conceit here is

by RogerL 12y ago

plorkyeran 12y ago

> we care about the type of x because we need to cast to a 16-bit int because it is going to be use to communicate with hardware IMO you should still use auto there and use a static_cast<int16_t> on the RHS to make it clear to the reader that you're deliberately converting it.

RogerL 12y ago
You're right.

yongjik 12y ago

Problem arises when we find "y" deep in a function, searches for its definition, and encounters "auto y = std::move(x);". Now we have to know the type of x, and if x is defined similarly, up the chain. Not fun. foo(A * x) doesn't pose similar problem. On the other hand, if I write auto bar = foo(A*x); Then we can have the same problem (esp. if foo is a templated function).

mpyne 12y ago
> Problem arises when we find "y" deep in a function, searches for its definition, and encounters "auto y = std::move(x);". This is gun control applied to computer languages. The solution is not to ban a useful feature that would ordinarily aid the understandability of code, the solution is to not abuse such features to write gibberish. People can write spaghetti code with any syntax you provide them, even Python.
RogerL 12y ago
To be honest, I just hover my mouse over 'bar' to get the type, and I name 'bar' something more meaningful than bar. "ball_covariance", "movie_recommendations", or whatever that matrix multiplication is computing for me. I wrung my hands when I started using 'auto' but none of the worries came to pass. But yes, if the code is unreadable without a type, add a type. No biggie, and no one is suggesting inflexible application of rules (always use 'auto' if it is possible). The same way when I might call foo(boo(x)); and it is not clear, I'll explicitly name the output of boo in a temporary variable: auto robot_velocity = boo(x); auto robot_covariance = foo(robot_velocity); And if that ain't enough, then sure, do this: robot::vector<float> robot_velocity = boo(x); robot::matrix<float,float> robot_covariance = foo(robot_velocity); I have to say, I find the last the most unreadable. I almost never care deeply about the type, and care deeply about the meaning. Interestingly, no one worries about typedef. typedefs wrapped around intricate collections (map of lists of dictionary of arrays) can effectively obscure what the underlying types are just as much as auto. But again, mouse hover, CTRL+I, or whatever your IDE supplies pretty much makes that a non-issue as well. edit: the problem you are describing is due to too big a function, not 'auto'.
stinos 12y ago
when we find "y" deep in a function There should be no such thing as deep in a function, or at least not as deep as you mean (i.e. so deep that you can't figure out what y is): that would in all likelyhood mean your function is too long, has too much responsabilities. Good functions are short and composed of other short functions, they should be short enough so that you can read them through without ever having to wonder 'wtf is this?' I know this might sound like textbook stuff without practical use but it's simply the truth, as I learned through the years. In those years my functions only became shorter, and hence better named, and more reusable, and all code simpler to read. So auto was a godsend that didn't hurt once.