3 ms·

I have seen a lot of people say something like you did, and after one month working in a mostly-always-auto project they can't ever go back to writing types tha

I have seen a lot of people say something like you did, and after one month working in a mostly-always-auto project they can't ever go back to writing types that your compiler knows perfectly well. 99% percent of the time it is the interface that matters, and for the 1% remaining, sure, write your type.

IshKebab 8y ago
It's not the writing of auto that is the problem. I agree with op. I try to avoid auto if the type is short enough to easily type.
- stinos 8y ago
  But this introduces inconsistency and hurts readability and maintanability: sometimes auto, sometimes not, purley based on some arbitrary limit of amount of characters in the type name? I'm not advocating everything must be auto but surely there's better and more consistent rules than that.
  - IshKebab 8y ago
    I don't think it is an important inconsistency and I don't see why it would hurt maintainability. Maybe you're thinking "you can't change return types easily" but in practice the situations where you can change a return type without altering calling code at all are extremely rare. Also, I agree that there could be a better solution - always use auto, and use an IDE which shows you the type inline. IntelliJ can do this for Rust. But unfortunately no C++ IDE has code intelligence anywhere near good enough to do this reliably.
    - jcelerier 8y ago
      > Also, I agree that there could be a better solution - always use auto, and use an IDE which shows you the type inline. IntelliJ can do this for Rust. But unfortunately no C++ IDE has code intelligence anywhere near good enough to do this reliably. I guess it depends on the IDE, here's what the one I use (QtCreator) can do for instance : https://i.imgur.com/SebyTR9.png https://i.imgur.com/SebyTR9.png
      - IshKebab 8y ago
        I used QtCreator. It's good but not reliable or fast enough for large projects.
stinos 8y ago
This, I think. Whenever I see heavy anti-auto statements I can't help but wonder whether the author actually ever used auto (or var, or dynamically typed languages) for a while and not just read about it and thought 'wow this is radically different from what I do so it must be bad' (note: been there, done that). I mean sure everybody can have their opinion, but if you have millions using languages without bothering about types and you have the C++ gurus telling you to almost always auto then surely some bells should start ringing that maybe, just maybe, its not that bad.
- gambiting 8y ago
  So personally I have tried it with the projects we work on(large, heavily templated C++ projects) and issues I have is that using auto confuses the hell out of VisualAssist and Intellisense(80% of the time they just can't guess what the type actually is so I get no autocomplete on any methods, which slows me down hugely) but the worst part is that the debugger doesn't know either - so any time I get a crash with auto I need to spend additional few minutes to find the actual type(and the right template!) and cast it manually in the watch window, because the debugger either straight up doesn't know, or is inferring the type incorrectly(which is actually worse than not knowing). That's in VS2015 with both MSVC and Clang. It's great on smaller projects and I have used it for few tools that I wrote - but the larger projects, no thanks. In general our code standard only allows auto if the type is defined immediately before it(so if you create a vector and then want a for loop immediately below it, then it's fine to use auto for the loop, otherwise no).
  - jcelerier 8y ago
    > So personally I have tried it with the projects we work on(large, heavily templated C++ projects) and issues I have is that using auto confuses the hell out of VisualAssist and Intellisense(80% of the time they just can't guess what the type actually is) that's a problem with your IDE, I use QtCreator which leverages clang for parsing and gets it right the immense majority of time in my experience. > but the worst part is that the debugger doesn't know either - so any time I get a crash with auto I need to spend additional few minutes to find the actual type(and the right template!) and cast it manually in the watch window, this sounds like a deeper bug with VS. I use debugging with cdb, windbg, and VS IDE, and the debugger never had trouble with "auto" variables - I don't understand why it would, since in the binary debug info it's the actual type which is saved. Did you report it to MS ? I don't know how large is your project, the main one I'm working on is overall a bit more than 300kloc and VS2017 had no problems with it last time I had to use it for reference.

IshKebab 8y ago

It's not the writing of auto that is the problem. I agree with op. I try to avoid auto if the type is short enough to easily type.

stinos 8y ago
But this introduces inconsistency and hurts readability and maintanability: sometimes auto, sometimes not, purley based on some arbitrary limit of amount of characters in the type name? I'm not advocating everything must be auto but surely there's better and more consistent rules than that.
- IshKebab 8y ago
  I don't think it is an important inconsistency and I don't see why it would hurt maintainability. Maybe you're thinking "you can't change return types easily" but in practice the situations where you can change a return type without altering calling code at all are extremely rare. Also, I agree that there could be a better solution - always use auto, and use an IDE which shows you the type inline. IntelliJ can do this for Rust. But unfortunately no C++ IDE has code intelligence anywhere near good enough to do this reliably.
  - jcelerier 8y ago
    > Also, I agree that there could be a better solution - always use auto, and use an IDE which shows you the type inline. IntelliJ can do this for Rust. But unfortunately no C++ IDE has code intelligence anywhere near good enough to do this reliably. I guess it depends on the IDE, here's what the one I use (QtCreator) can do for instance : https://i.imgur.com/SebyTR9.png https://i.imgur.com/SebyTR9.png
    - IshKebab 8y ago
      I used QtCreator. It's good but not reliable or fast enough for large projects.

stinos 8y ago

This, I think. Whenever I see heavy anti-auto statements I can't help but wonder whether the author actually ever used auto (or var, or dynamically typed languages) for a while and not just read about it and thought 'wow this is radically different from what I do so it must be bad' (note: been there, done that). I mean sure everybody can have their opinion, but if you have millions using languages without bothering about types and you have the C++ gurus telling you to almost always auto then surely some bells should start ringing that maybe, just maybe, its not that bad.

gambiting 8y ago
So personally I have tried it with the projects we work on(large, heavily templated C++ projects) and issues I have is that using auto confuses the hell out of VisualAssist and Intellisense(80% of the time they just can't guess what the type actually is so I get no autocomplete on any methods, which slows me down hugely) but the worst part is that the debugger doesn't know either - so any time I get a crash with auto I need to spend additional few minutes to find the actual type(and the right template!) and cast it manually in the watch window, because the debugger either straight up doesn't know, or is inferring the type incorrectly(which is actually worse than not knowing). That's in VS2015 with both MSVC and Clang. It's great on smaller projects and I have used it for few tools that I wrote - but the larger projects, no thanks. In general our code standard only allows auto if the type is defined immediately before it(so if you create a vector and then want a for loop immediately below it, then it's fine to use auto for the loop, otherwise no).
- jcelerier 8y ago
  > So personally I have tried it with the projects we work on(large, heavily templated C++ projects) and issues I have is that using auto confuses the hell out of VisualAssist and Intellisense(80% of the time they just can't guess what the type actually is) that's a problem with your IDE, I use QtCreator which leverages clang for parsing and gets it right the immense majority of time in my experience. > but the worst part is that the debugger doesn't know either - so any time I get a crash with auto I need to spend additional few minutes to find the actual type(and the right template!) and cast it manually in the watch window, this sounds like a deeper bug with VS. I use debugging with cdb, windbg, and VS IDE, and the debugger never had trouble with "auto" variables - I don't understand why it would, since in the binary debug info it's the actual type which is saved. Did you report it to MS ? I don't know how large is your project, the main one I'm working on is overall a bit more than 300kloc and VS2017 had no problems with it last time I had to use it for reference.