template<typename Range>
auto begin(Range& r) -> decltype(r.begin()) {
return r.begin();
}
[0] In this specific case you could require that Range have an iterator typedef and return that, but that approach does not generalize.
If someone starts using auto for every variable or returning it from every method, then they need a stern talking-to.
http://herbsutter.com/2013/06/07/gotw-92-solution-auto-varia...
http://herbsutter.com/2013/06/07/gotw-93-auto-variables-part...
http://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-...
He has some good points, but his perspective seems to be biased by a professional focus on writing libraries and more general-purpose code. He's also brilliant and can remember things like this:
const int& cir = val;
auto h = cir;
//The type of h is int.
Probably you expected |auto| to behave like |decltype()|, C++11's other form of type deduction, which gives you the actual type of an expression. C++14 adds |decltype(auto)|, which lets you declare local variables using this behavior if you want it.
I'm not sure whether I'd apply Herb's AAA rule quite as broadly as he suggests, but I think it's broadly right, because far too often in C++ we write a type twice on the same line, which is just redundant. I vastly prefer |auto val = new MyClass;| to |MyClass val = new MyClass;|, and similarly |auto casted = static_cast<MyType>(uncasted);| is completely readable without typing writing "MyType" a second time. C++ programmers are a conservative lot, but I expect using |auto| at least in those cases to be pretty mainstream within a few years.
It does not matter what the rationale behind the committee's decision was. This is standard practice in duck typed languages, and it will be adopted as well in C++, since it will be (imho, correctly) perceived as another step to bring C++ "to the 21th century".
You can stern-talk as much as you wish... but it won't have much effect unless backed up by an (effectively enforced) internal code style guide.
The barbarians are already at the gate. Which side are you going to pick?
Only because there is no choice in those languages -- and, in those language communities, there's considerable call for finding a good way to include optional explicit and enforced declared typing specifically so that a choice does exist.
So, even given that communities that (unlike C++, even with auto existing) accept languages that don't provide an alternative to to the equivalent of "auto everywhere" push back against that practice to the extent of seeking language features to provide an alternative to it, I don't think that auto becoming an option is going to mean auto everywhere takes over C++.
There'll probably be some overuse (particularly in a brief period before a widely-accepted conventions on appropriate use are established), but its hardly the most dangerously abusable feature of the C/C++ language family.
This is quite a narrow-minded line of thinking. You're saying "Feature X is should be excluded because of <possible consequence>". But we can say the converse about this same feature: "Feature Y should be included because <possible benefit>". Every programming language feature ever has had its pros and cons, and every language designer makes tradeoffs deciding which features to include and which to exclude.[1]
You also most likely overestimate the practical unreadability of the source code. IDEs are (or will be) smart enough to deduce and display the type of an auto declared variable[2] when you want it. For short functions, it will be blindingly obvious what the auto-declared return type of a function is. Using auto will vastly improve readability by reducing textual noise when a function returns (1) heavily templated expressions, (2) any type within a deeply-nested namespace, (3) any type with a long name, or especially (4) combinations of the previous three (e.g. std::vector::const_iterator< std::pair<std::string, double> >). Complicated types are a common issue in languages with static type systems[3].
I could go on. There are tons of use-cases where auto will help out. The biggest complaint I have is that you can auto-declare the return type of methods that return private variables from a class (unless I'm mistaken; I haven't actually tried it). This pokes leaky holes in your class's encapsulation, forming dependencies between external code and your class's private, internal implementation (although this may be possible through template magic...).
The barbarians are already at the gate. Which side are you going to pick?
Oh, cut the drama. Every language has some sort of a style guide, and C++ programmers are already used to following a style guide and programming with discipline. One more feature with a few downsides and a number of benefits is not going to make a difference, and is totally in line with its philosophy[1].
1: http://en.wikipedia.org/wiki/C%2B%2B#Philosophy 2: http://stackoverflow.com/q/19625115 3: https://github.com/rust-lang/rust/issues/10448
Not to detract from your other points, but personally I wouldn't want to live in a world where my IDE is decided for me. A person sometimes has decades of experience with their text editor. Forcing them to use a different one just to do programming isn't necessarily the best idea.
Interesting question: Will the world benefit from a language that requires an IDE to program in? I can imagine how the answer might be "yes," but also other scenarios where it might be "no."
Anyway, they are talking about documentation. Many people think that having to peek inside a function to know what it returns is worse than having a compiler-checked type declaration. In fact, in most languages with type inference there is still a strong convention to write full signatures for all top level functions, as a form of documentation (return type inference is left for lambdas)
if (!arg1 || !arg2 || !arg3 ...) {
what_I_should_do_here_isnt_really_clear();func_call(&var1);
is most definitely a C++ convention bud, and it has nothing to do with google.
Not only did you need to use the type correctly, but you needed to declare the desire to use a specific type from the get-go.
Maybe such a tool for C++ will also appear?
An auto return type means the type is inferred from the type of the expression that the function returns, so it's known from that.
Say I have a header file "foo.h" with an "auto foo();" declaration. Another file (eg, "bar.h") imports foo.h. How can the compiler do type checking when compiling bar.cc without also parsing foo.cc to determine the return type of foo()?
To quote:
> Of course, this requires the function body to be visible.
https://isocpp.org/wiki/faq/cpp14-language#generalized-retur...
Requiring pointless verbosity on some hope that somehow that'll help bad programmers write better code seems like an odd conclusion.
Its kind of weird to see people complaining about a C++ feature because its not appropriate to use indiscriminately and requires some discipline -- that's historically been pretty much the whole of C/C++.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n363...:
Of course, using such a function in an expression when
only a forward declaration has been seen is ill-formed:
auto f(); // return type is unknown
int i = f(); // error, return type of f is unknown
Of course, this requires the function body to be visible.Then, we do use template parameters already, for which we usually don't know the type. I can't see why we'd bitch about 'auto' and not about the template parameters.
It's just the same thing: coding against interfaces and not implementations.
I prefer to make functions ordinary, and only templatize functions that need to operate on more than one type. There's good reasons for this: the compiler is less effective at type-checking templates, they require the function body to be visible, and they may fail to warn you when passed the wrong type.
"auto" suffers from all those problems, and yet we are being told to use it whenever possible. That's bad advice.
map<unsigned int, map<int, vector<string>::iterator> >::iterator getSomeIterator();
or:
auto getSomeIterator();
Function name and context usually is sufficient to know what SomeIterator refers to, there is no need for horrible STL constructs to try to explain it.
std::map<unsigned int, std::map<int, std::vector<std::string>::iterator> >::iterator getSomeIterator();
I believe you don't need the space between the > > any more, since C++11?
In most cases you can scan over the type ('map blah blah...iterator') but that's not reading and in any case will quickly fail you with nested template types, if you're unfortunate enough to have those.
And whether a function returns an iterator is not consistent even within the STL:
auto loc = container.find("name");
If you had used the explicit iterator type, you would at least get an error message immediately with the above line, instead of hoping your code does something that size_t doesn't support.
MY_TYPE::iterator getSomeInterator();You have a point there
what you could do is:
return (int)x;
return (YourClass)value;
(then the header and implementation are auto but you still know what the code is talking about
(Or just put the type there as usual)