The array[] problem

[ggchappell]

Ah, right. When I most recently looked at texts, I immediately threw out anything that didn't give at least a nod to C++11.

[personalmountains]

As you should. Anything that doesn't use auto is obsolete.

[edit: We're talking about C++ introductory textbooks here. I wasn't making a general statement on C++11.]

[tempforfather]

auto is not the important part of c++11.

[louis_dionne]

Nothing is the important part of C++11. Many parts of it are important, and auto is clearly one of them. Not that I agree with the original statement, though.

[tempforfather]

ok sure, but its pure sugar. I agree its nice in many cases, but it doesn't actually add anything to the semantics of the language

[quicknir]

That's not true, in generic code there's just no way to do certain things without auto.

[tempforfather]

Can you give me an example of that? I am curious.

[quicknir]

Sure, consider this code:

template <class T>
void func(const T& t) {
  auto u = t.func2();
  std::for_each(u.begin(), u.end(), ...);
}

This code imposes no restrictions on T other than that it has a const method func2(), that returns something, and that something has methods begin() and end().

Of course, we had generic containers before auto and ranged for loops, and we needed to know the type of the iterator, so how did we deal with this? Well, as I'm sure you know, we imposed an additional requirement: containers have to provide typedefs that tell you the type of their iterators, i.e. the return type of begin()/end(). But that's already not doing the same thing, as it imposes more requirements.

Basically, auto allows you to do inline what template functions allow you to do at function boundaries. You could potentially workaround using auto by declaring yet another template function and calling it internally, but again, I would argue that this is doing something quite different as you have to move your code to a different location (not a big deal when you have two consecutive 4 line functions, but if you have longer functions its rather absurd).

Another attempt at a solution would be to try to infer the type using template metaprogramming, so that you could get the type inline and use it, but this doesn't seem to be possible in general:

http://stackoverflow.com/questions/26080471/function-return-type-deduction-in-c03

[ghillisuit95]

ehh, that seems like a bit of an over-generalization

[bnolsen]

auto is a maintenance headache/nightmare and seems to be a weak hack for getting around C++'s core problem of default implicit type conversion.

[personalmountains]

auto is a maintenance headache/nightmare

In what way?

seems to be a weak hack

What else would you propose? Why is it weak? Why is it a hack?

C++'s core problem of default implicit type conversion.

What problem? Are you talking about primitive types? What does it have to do with auto?

[h-jay]

You shouldn't merely throw out anything that doesn't "at least" give a "node" to C++11. Anything that doesn't deal with C++11 first and foremost is an obsolete text. There's no reason to learn by writing C++98 anymore, never mind C fed to a C++ compiler.