6 ms·
Using 'auto' for return types seems just awful to me. In the context of a collaborative project, I don't want to have to dig through the implementation of someo
by seccess 12y ago
Using 'auto' for return types seems just awful to me. In the context of a collaborative project, I don't want to have to dig through the implementation of someone else's function just to figure out what type it returns. Having an explicit return type is a form of self-documenting code.
- seren 12y agoNow, for the fun part, imagine you have to integrate a third-party cpp library, with an API like "auto fooBar()".
- dragonwriter 12y agoSure, auto probably shouldn't be used on a function that's part of the exposed API of a library, rather than something internal to the unit of code it is part of. 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++.
- seren 12y agoMy comment was mostly tongue-in-cheek, it will be misused in some time and place, but is not a serious issue.
- Someone 12y agoA third party can do that but if it doesn't also provide the source for fooBar, you won't be able to call it, making it fairly useless. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3638.html 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 And https://isocpp.org/wiki/faq/cpp14-language#generalized-return https://isocpp.org/wiki/faq/cpp14-language#generalized-retur...: Of course, this requires the function body to be visible.
- freditup 12y agoAgreed - the popularity of implicit typing is surprising to me. It seems to make code much less readable and comprehensible. In a good IDE I suppose it doesn't really matter because type information could be provided automatically, but code isn't always read in a good IDE.
- Ragnarork 12y agoIn fact, with an IDE, this argument is moot. You can have the type anyway. 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.
- JoeAltmaier 12y agoTemplate is explicit; auto can sneak under your radar and look like things you already think you know how they work. Any change to the mainstream syntax can be troublesome at first.
- Ragnarork 12y agoI don't see how auto is less explicit than a template when it comes to involving implicit interfaces.
- millstone 12y agoA key difference is that we are being told to use auto (but not templates) gratuitously, even when there's only one possible type. 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.
- kruczek 12y agoWhich is much less readable: 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.
- pyrois 12y agoI think in any sane library, public API functions will have declared return types. It's only for small helper functions inside a source file that will be autoed. I agree that misuse of auto is going to be terrible, though.
- dangerlibrary 12y agoThat's a reasonable position, but the popularity of languages without any type declarations at all suggests that there are many people who don't mind. (python, ruby, etc.)
- JoeAltmaier 12y agoAnd 'auto' isn't the same as no type declaration. Auto still enforces type consistency, so its not that foreign to existing C++ expectations.
- ufo 12y agoHaving the type be inferred is precisely what omitting a type declaration does in a static language. From the point of view of a pedantic type systems theorist, Python is like having a static language where every variable has the the same type, "Object". 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)
- mreiland 12y agoI suspect that over time the C++ community will settle on a set of conventions around the use of auto in this context. Much like how passing in a mutable reference is considered a no-no and you're expected to instead pass in a mutable pointer so it's obvious to the caller that you can change the value via the parameter list.
- femngi 12y agoThat's not a C++ community convention, it's just another bone headed part of the Google C++ coding standards. It's stupid because now everything is potentially nullable and every single function will start with: if (!arg1 || !arg2 || !arg3 ...) { what_I_should_do_here_isnt_really_clear();
- panzagl 12y agoYeah, we'll end up with some type of Hungarian notation for function naming. A lot of 'Modern C++' seems to be taking over what is really the job of an IDE, just because the original C++ syntax was so verbose.
- raverbashing 12y agoEdit: see child comments to see why this is a bad idea, at least with native types. Maybe typeid() is better 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)
- Ragnarork 12y agoExcept you may have a conversion and you don't know it.
- kruczek 12y agoSame can be said about using 'auto' for variable type declarations. It all comes down to "use, but don't abuse" (as most things in C++) - it can improve readability, if used moderately; and it is up to the programmer to judge where to use it.
- sampo 12y agoThe compiler knows the inferred types anyway. And several other languages have tools to query these types. Maybe such a tool for C++ will also appear?
- Pxtl 12y agoType inference has been a fantastic blessing for me in C#, so I'll never complain about having to type locals... by extension, implicitly-typed privates seems to make sense. But the public interface of a class? That just feels one step too far.
- MichaelGG 12y agoWhat if it's a private interface, like a local function? Or a public interface with limited consumers? The language should allow you to write your code the way you want. Requiring pointless verbosity on some hope that somehow that'll help bad programmers write better code seems like an odd conclusion.
- jibsen 12y agoWhat happens if a header file declares a function to return auto, does the compiler have to wait until link time to find out what the type is?
- missblit 12y agoNo, types are completely determined before link time. 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.
- seccess 12y agoInteresting, could you elaborate on this a bit more? 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()?
- mkup 12y agoIf there's no function body in header (non-inline function), then it won't compile.
- deleted 12y ago[deleted]
- nanofortnight 12y agoInferrence isn't magic and has sensible limits. To quote: > Of course, this requires the function body to be visible. https://isocpp.org/wiki/faq/cpp14-language#generalized-return https://isocpp.org/wiki/faq/cpp14-language#generalized-retur...
- ludamad 12y agoNote that this can be used for static functions, I don't think anyone would find it in an API documentation. The real reason I see for this is reducing voodoo in template libraries, eg forwarding a call T::something() for a generic type 'T'.
- plorkyeran 12y agoThe primary use-case of auto returns is for templated functions where the return type depends on the thing passed in. For example, in C++11 you have to write things like the following: template<typename Range> auto begin(Range& r) -> decltype(r.begin()) { return r.begin(); } The return type can't be specified by the function[0], and you have to copy and paste the body of the function into the decltype() clause to tell the compiler that the return type is whatever the thing it's wrapping returns. When you have some long and complicated expression rather than just r.begin() in the body, this duplication becomes a major issue. [0] In this specific case you could require that Range have an iterator typedef and return that, but that approach does not generalize.
- deleted 12y ago[deleted]
- jobu 12y agoC++ templates used to be the most unreadable code this side of Perl, but with auto and a little documentation you can figure out what's happening fairly easily. Templates (and auto) are typically used when dealing with core libraries and should be documented better than average code anyway. If someone starts using auto for every variable or returning it from every method, then they need a stern talking-to.
- RogerL 12y agoThen start with Herb Sutter, because that is exactly his advice at the latest CppCon.
- jobu 12y agoYes, and he's said that in a few blog posts as well: http://herbsutter.com/2013/06/07/gotw-92-solution-auto-variables-part-1/ http://herbsutter.com/2013/06/07/gotw-92-solution-auto-varia... http://herbsutter.com/2013/06/07/gotw-93-auto-variables-part-2/ http://herbsutter.com/2013/06/07/gotw-93-auto-variables-part... http://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/ 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. It's difficult to make generic rules for how to use C++ (because it's used for everything from adware to nuclear reactors), but I can say that Herb's AAA (Almost Always Auto) rule would not fly on any development team I've ever worked with.
- PoL0 12y agoJust gather the result in an auto (auto&, const auto&,...) variable et voilà
- deleted 12y ago[deleted]