6 ms·

Agreed - 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

Agreed - 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 ago
In 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 ago
  Template 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 ago
    I don't see how auto is less explicit than a template when it comes to involving implicit interfaces.
- millstone 12y ago
  A 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 ago
Which 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.
- RogerL 12y ago
  Or, more likely std::map<unsigned int, std::map<int, std::vector<std::string>::iterator> >::iterator getSomeIterator();
- 72deluxe 12y ago
  The first is readable and I know what it is. Not as readable, but at least I know what it is! I believe you don't need the space between the > > any more, since C++11?
  - seabee 12y ago
    Readability is about how quickly you can figure out what's going on. There are only a few bits of syntax you need to know what's going on in the first example, but it requires mentally matching together the angle brackets correctly, and it emphasises the type over the function name. 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.
    - millstone 12y ago
      Functions that return iterators are never called getSomeIterator(). Instead they're called stuff like erase(), insert(), or even nonsense words like crend(). And whether a function returns an iterator is not consistent even within the STL: auto loc = container.find("name"); What type is loc? If container is a std::map, then loc is an iterator. If container is a std::string, then loc is a size_t. 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.
Guvante 12y ago
Remember this is primarily for non-public facing or complex objects. If you are looking at someones API on github it should not be using auto for return types.

Ragnarork 12y ago

In 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 ago
Template 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 ago
  I don't see how auto is less explicit than a template when it comes to involving implicit interfaces.
millstone 12y ago
A 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 ago

Which 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.

RogerL 12y ago
Or, more likely std::map<unsigned int, std::map<int, std::vector<std::string>::iterator> >::iterator getSomeIterator();
72deluxe 12y ago
The first is readable and I know what it is. Not as readable, but at least I know what it is! I believe you don't need the space between the > > any more, since C++11?
- seabee 12y ago
  Readability is about how quickly you can figure out what's going on. There are only a few bits of syntax you need to know what's going on in the first example, but it requires mentally matching together the angle brackets correctly, and it emphasises the type over the function name. 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.
  - millstone 12y ago
    Functions that return iterators are never called getSomeIterator(). Instead they're called stuff like erase(), insert(), or even nonsense words like crend(). And whether a function returns an iterator is not consistent even within the STL: auto loc = container.find("name"); What type is loc? If container is a std::map, then loc is an iterator. If container is a std::string, then loc is a size_t. 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.

Guvante 12y ago

Remember this is primarily for non-public facing or complex objects. If you are looking at someones API on github it should not be using auto for return types.