5 ms·
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 langua
by 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 agoSo 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.
- stinos 8y agoThanks for sharing, didn't know this was still as bad as you describe. Despite having a considerable amount of template code as well we don't have problems to the degree you mention - especially not in the debugger (but only when compiled in debug without optimizations, not in release, but that's sort of expected). We do use VS2017 though, and basically ditched VAssistX after moving to it because the built-in intellisesne was good enough. It's not like literally everything works, but it's usable enough. Apart from that I also have an impression, not measurable, that since a couple of years using auto we somehow got used to it and don't have to rely on intellisense etc. Sounds like a contradiction, and might not have anything to do with auto but just C++ in general or even just the team becoming better, but it's like the code is more generic and cares less about exact types but still has less bugs because it's easier to reason about.