C++ 11 Auto: How to use and avoid abuse
acodersjourney.com
C++ 11 Auto: How to use and avoid abuse
1–10 of 47 posts
Re: C++ 11 Auto: How to use and avoid abuse
#2Unsure of the explicit typing one. Don't the Core Guidelines say to use it in that case? The IDE's going to tell you the return type anyway.
Re: C++ 11 Auto: How to use and avoid abuse
#3How much of these concerns could be alleviated by an IDE that makes the types more visible?
Re: C++ 11 Auto: How to use and avoid abuse
#4How much of these concerns could be alleviated by an IDE that makes the types more visible?
That's what Herb Sutter argues in his Almost Always Auto post, but I would disagree:
1. The IDE cannot deduce the type within templates, and more code is moving to templates (e.g. generic lambdas in C++14)
2. Code is often read outside of IDEs: code review, search engines, etc.
3. Should C++ become a language that requires an IDE to work effectively, like Java? Probably not.
Re: C++ 11 Auto: How to use and avoid abuse
#5auto, the new range for and lambdas are my most used C++11 features. Also make_shared/make_unique.
auto ptr = make_shared()
[](a,b){ ... }
[](int a, int b) {...}
[](auto a, auto b) {...}
Re: C++ 11 Auto: How to use and avoid abuse
#6"auto a = ConjureMagic();"
"SetMagic(a);"
The problem here is actually is an old one of failing to separate a getter from a command.
It looks like ConjureMagic is causing side effects and modifying the state of whatever class it belongs to.
This is also the reason one can't answer the question "what the heck is a?". If the "ConjureMagic" is only a getter and does not modify class state, it may probably need a better name, like "GetMaxMagicPossible". That renders an auto no longer confusing, because this name explains more than the return type. If, on the other hand this is just a command to conjure the magic and we are getting the remaining amount only to immediately pass it to the member "SetMagic" function, then there was no point in returning this value - it could be done inside the "ConjureMagic" itself.
Re: C++ 11 Auto: How to use and avoid abuse
#7How much of these concerns could be alleviated by an IDE that makes the types more visible?
That's what Herb Sutter argues in his Almost Always Auto post, but I would disagree: 1. The IDE cannot deduce the type within templates, and more code is moving to templates (e.g. generic lambdas in C++14) 2. Code is often read outside of IDEs: code review, search engines, etc. 3. Should C++ become a language that requires an IDE to work effectively, like Java? Probably not.
I would be very surprised if someone can meaningfully review C++ templates without an IDE.
Really not reviewing a program inside an IDE is a poor idea in general.
Re: C++ 11 Auto: How to use and avoid abuse
#8I'd be more than annoyed if I saw someone name a function "xxInteger()" because it returns an integer.
I don't actually think the first example was that bad, modulo some context. Sometimes even knowing the type for this kind of thing isn't super important to understand what the code is doing; ala opaque types.
Re: C++ 11 Auto: How to use and avoid abuse
#9Somewhat related, C++14 gets 'auto' for function return types, which really makes me nervous (C++11 has a form of this, but not as powerful).The D programming language uses 'auto' as the return type for many of the functions in the standard library and this makes it, IMO, somewhat cumbersome to use.
In general, I don't think C++ (or D) devs should be using deduced return types in the public interface, if at all possible.
Re: C++ 11 Auto: How to use and avoid abuse
#10Earlier quoted context omitted.
That's what Herb Sutter argues in his Almost Always Auto post, but I would disagree: 1. The IDE cannot deduce the type within templates, and more code is moving to templates (e.g. generic lambdas in C++14) 2. Code is often read outside of IDEs: code review, search engines, etc. 3. Should C++ become a language that requires an IDE to work effectively, like Java? Probably not.
I would be very surprised if someone can meaningfully review C++ templates without an IDE. Really not reviewing a program inside an IDE is a poor idea in general.
Some of us still use emacs and vim.