5 ms·

Only slightly related, but I feel (I do not yet have the experience) that 'auto' is going to make the lives of those reading code 10x harder, for the benefit of

by roel_v 13y ago

Only slightly related, but I feel (I do not yet have the experience) that 'auto' is going to make the lives of those reading code 10x harder, for the benefit of those writing code to have to think and type tiny amounts less, and for the writers of template libraries to have to think 10 times less. Especially that last part concerns me great amounts. I'm not looking forward to the first time I will have to work myself into a code base build around heavy 'auto' use.

nikbackm 13y ago
OTOH, with auto the reader never have to worry about narrowing conversions. And any decent IDE should show the deduced type for an auto variable on demand.
- roel_v 13y ago
  "And any decent IDE should show the deduced type for an auto variable on demand." Eh... That can only be done by compiling the code in the background, while you're typing. Which is possible, of course, but it sets a very high barrier for tools. It will mean that only the top-3 of IDE's will provide this functionality, and even then, it will take them years to get it working well.
ygra 13y ago
(C++ beginner here) I tend to use the actual type for simple enough types, typdef those template instantiations I use frequently and use auto more or less only for iterators (which are horrible to write otherwise, especially for things like map<foo, vector<bar>>).
- roel_v 13y ago
  It's for iterators, and similar template-heavy types, that you need them the most. Well not for an iterator over an std::vector<double> obviously, but the worse the amount of typing for the type gets, the more you need to know the actual type to save you from having to do the type deduction in your head every time. (well not 'you' in the sense of 'the author', the whole problem it's that it's the people who need to read the code afterwards need the full type the most, the incentives are so misaligned). I guess the more I think about it, that that's what scares me the most about 'auto' - instead of having the original author do the type deduction once (which is something he intended in the first place, hopefully), you now (as a maintainer) have to go chase it down, just to save the original author from typing out a hairy type. Now I do realize the real use case for 'auto' - it's the cases where you don't actually know the type yet, because you're providing an extensible framework through template specialization. I have written quite a bit of such code myself. And yet, despite having suffered through all the 5-line typedefs that that sometimes required, I'd be willing to keep doing that to save myself from code by people who mistake 'auto' for a convenient way to save a few keystrokes (this is not meant as a jab at the parent, I'm just talking in general, in case anyone would interpret me wrong).
  - Executor 13y ago
    Auto is useful to reduce the amount of typing and DRY principle. Your arguments are meaningless when you can hover the mouse on the "auto" keyword and have Visual Studio/Eclipse tell you its type.
stinos 13y ago
Maybe for programmers that are only used to reading C, pre-C++11 and the likes. On the other hand when you are used to read more dynamic languages where typenames are much less written down literally (say C#/Python/Matlab just to name what comes up in my head), it doesn't make much difference. I'm also not sure if it makes that much of a difference for templates? Those are already quite type-agmostic. E.g. if your template typename is T, there's not much difference in writing `auto x = T()` vs `T x = T()`. Except the (imo) improvement that you are not repeating yourself in the auto case.
- roel_v 13y ago
  Yes, certainly as you say, which is what concerns me - the notion that types are something that is best buried, by an influx of new users. And certainly - the case of auto x = T(); is not too bad. It's when the type is determined by template overload, or Koenig lookup, or template traits, that it becomes murky. It will take years for tool to catch up - now when I put my cursor on a variable, it will show me the type in the status bar. For the first few years this will always show 'auto' I'm afraid. In other languages, a collection is a collection (mostly) - in C++ it depends on whether you use a vector, set, hash or list what methods are available. That's quite a difference, from a programming comfort point of view.
  - stinos 13y ago
    the notion that types are something that is best buried that was not really my claim though - types should not be buried in C++. Either the context should be clear enough to know what type it is. Or, like for lots of template code, the type simply should not matter. Obviously in those cases auto shines. In other words: if the code is written properly it shouldn't matter if auto is used or not. (and in my experience if all your functions are nice and short, as they should be 99% of the time) You do have a good point about the tooling though (which tooling is it you use btw? Haven't used anything but VS lately, and it's ok for the way I use it, but I can imagine having to go from clearly seeing all types to not being able to is an awful experience)
    - 13y ago
jerf 13y ago
Many, many languages already have the equivalent. It doesn't ruin code comprehensibility in any of them, and is generally considered a net positive. If C++ is too complex for it to work, I'm just going to consider that a strike against C++ and move on. Chalk it up as another piece of evidence that C++ is wildly more complicated than Haskell.

by roel_v 13y ago

nikbackm 13y ago

OTOH, with auto the reader never have to worry about narrowing conversions. And any decent IDE should show the deduced type for an auto variable on demand.

roel_v 13y ago
"And any decent IDE should show the deduced type for an auto variable on demand." Eh... That can only be done by compiling the code in the background, while you're typing. Which is possible, of course, but it sets a very high barrier for tools. It will mean that only the top-3 of IDE's will provide this functionality, and even then, it will take them years to get it working well.

ygra 13y ago

(C++ beginner here) I tend to use the actual type for simple enough types, typdef those template instantiations I use frequently and use auto more or less only for iterators (which are horrible to write otherwise, especially for things like map<foo, vector<bar>>).

roel_v 13y ago
It's for iterators, and similar template-heavy types, that you need them the most. Well not for an iterator over an std::vector<double> obviously, but the worse the amount of typing for the type gets, the more you need to know the actual type to save you from having to do the type deduction in your head every time. (well not 'you' in the sense of 'the author', the whole problem it's that it's the people who need to read the code afterwards need the full type the most, the incentives are so misaligned). I guess the more I think about it, that that's what scares me the most about 'auto' - instead of having the original author do the type deduction once (which is something he intended in the first place, hopefully), you now (as a maintainer) have to go chase it down, just to save the original author from typing out a hairy type. Now I do realize the real use case for 'auto' - it's the cases where you don't actually know the type yet, because you're providing an extensible framework through template specialization. I have written quite a bit of such code myself. And yet, despite having suffered through all the 5-line typedefs that that sometimes required, I'd be willing to keep doing that to save myself from code by people who mistake 'auto' for a convenient way to save a few keystrokes (this is not meant as a jab at the parent, I'm just talking in general, in case anyone would interpret me wrong).
- Executor 13y ago
  Auto is useful to reduce the amount of typing and DRY principle. Your arguments are meaningless when you can hover the mouse on the "auto" keyword and have Visual Studio/Eclipse tell you its type.

stinos 13y ago

Maybe for programmers that are only used to reading C, pre-C++11 and the likes. On the other hand when you are used to read more dynamic languages where typenames are much less written down literally (say C#/Python/Matlab just to name what comes up in my head), it doesn't make much difference. I'm also not sure if it makes that much of a difference for templates? Those are already quite type-agmostic. E.g. if your template typename is T, there's not much difference in writing `auto x = T()` vs `T x = T()`. Except the (imo) improvement that you are not repeating yourself in the auto case.

roel_v 13y ago
Yes, certainly as you say, which is what concerns me - the notion that types are something that is best buried, by an influx of new users. And certainly - the case of auto x = T(); is not too bad. It's when the type is determined by template overload, or Koenig lookup, or template traits, that it becomes murky. It will take years for tool to catch up - now when I put my cursor on a variable, it will show me the type in the status bar. For the first few years this will always show 'auto' I'm afraid. In other languages, a collection is a collection (mostly) - in C++ it depends on whether you use a vector, set, hash or list what methods are available. That's quite a difference, from a programming comfort point of view.
- stinos 13y ago
  the notion that types are something that is best buried that was not really my claim though - types should not be buried in C++. Either the context should be clear enough to know what type it is. Or, like for lots of template code, the type simply should not matter. Obviously in those cases auto shines. In other words: if the code is written properly it shouldn't matter if auto is used or not. (and in my experience if all your functions are nice and short, as they should be 99% of the time) You do have a good point about the tooling though (which tooling is it you use btw? Haven't used anything but VS lately, and it's ok for the way I use it, but I can imagine having to go from clearly seeing all types to not being able to is an awful experience)
  - 13y ago

jerf 13y ago

Many, many languages already have the equivalent. It doesn't ruin code comprehensibility in any of them, and is generally considered a net positive. If C++ is too complex for it to work, I'm just going to consider that a strike against C++ and move on. Chalk it up as another piece of evidence that C++ is wildly more complicated than Haskell.