C++ Tutorials and C++0x Auto

[anonymous23323124]

So I am planning the fourth video in my C++ tutorial series, which is going to be about variables.

Now, just today I discovered the joys of the C++0x auto keyword (http://www2.research.att.com/~bs/C++0xFAQ.html#auto )

When I am recording the tutorial, I am considering mentioning this, as it is supported already by VC2010 and MinGW.

However, I wonder if telling new programmers about this, especially if they are familiar with languages more relaxed about types, is a bad idea. Perhaps they would just use it absolutely all the time instead of specific types.

What are your opinions, people? Do I include it with a warning or remove it in order to protect my viewers from themselves? ;)

[Veltas]

If you're going to the effort of not only making a video series but also specifically doing everything on code::blocks to make it easier for people who are too stupid to read, don't go and confuse them with different C++ specifications.

Auto may seem fun and bright to use but I'm not so sure I'll use it much, it looks like I'm going to easily confuse myself with it. I prefer well-defined code, you see, and code that automatically tries to give itself a type through a process which will likely be interpreted differently by every compiler doesn't feel too good, and is likely going to confuse new programmers too, giving them the false illusion that C++ will take kindly to screwing with types.

Also, I'm quite happy I never used auto with the old meaning in any of my code as now I'd have to go through and change all of it. This shouldn't be too much of a problem anyway, a simple search for and removal of all occurrences should work fine, as I'm pretty sure they made no difference whatsoever so code should function exactly the same without it.

Is this the first time the standard has completely changed the meaning of a keyword?

[anonymous23323124]

I'm not sure. But Dr. Stroustrup pointed out in his article that the old auto was completely useless. It was the default type specifier anyway, so the keyword was always irrelevant.

I had a resource manager which contained an std::map<const std::string, Resource*> where Reosurce was a template argument. I made this map type into a named type so if I changed it later, all the iterators wouldn't be incompatible

typdef std::map<const std::string, Resource*> ResourceList;
// etc
void fn() { ResourceList::iterator itr = Resources.begin(); /* etc */ }

The auto keyword would have formed a nicer solution to this one:
auto itr = Resources.begin();

However, you're probably right about the tutorials. Maybe I'll talk about it in something like video 50 (in the unlikely event that I get that far :P)

[Veltas]

Sounds like a safe idea.

Also, I like your example and you've definitely seen the good side of auto. However, that's the first level I'd actually use auto, and anything below that I'd use the proper types, since at the lower levels not using auto is just laziness and will generate a large magnitude of bad code. That's why it's a bad idea to give this to people just starting to learn C++, because they could only abuse it. Auto is definitely something you learn later on.

[anonymous23323124]

The credit for the example belongs to Dr Stroustrup ;)

He also pointed out it's usefulness in template programming, where you are, e.g. multiplying two template type variables. You can't imagine what the result might be, but it is obvious to the compiler when it has particular template arguments to work with.

And yeah, the abuse thing was what I was concerned about.

[Veltas]

Xander314 wrote:

He also pointed out it's usefulness in template programming, where you are, e.g. multiplying two template type variables. You can't imagine what the result might be, but it is obvious to the compiler when it has particular template arguments to work with.

I'm going to be honest, that's exactly the first thing I thought of when I found out about auto, word for word. Funny that.

Auto's going to be good, but I'm not going to get around to seriously considering using it in all my work until I've tried it out properly in a few tests.

[3hM2Nwbp]

Take it from me - once you start using auto, it's living hell to go back to the old way :P I had to 'fix' some heavily templated library code that I wrote in VS2010 to be compatible with VS2008 (*and GCC) and the whole process took me about 12 hours to get right.

[Veltas]

That's what I feared when they announced it, it seemed like a powerful tool that would be too easy too abuse.

[helios]

Of course you're going to have problems if you use a language feature that's not part of a given implementation, but arguing against auto because of this is like saying you shouldn't use the STL in case you need to compile with VC++ 6.0.

it seemed like a powerful tool that would be too easy too abuse

I don't see how that relates to Luc Lieber's example. In any case, I'm having a hard time picturing an abuse of auto, beyond the absurd case where nearly all locals are auto'd and the programmer has lost track of all types.

I prefer well-defined code, you see, and code that automatically tries to give itself a type through a process which will likely be interpreted differently by every compiler

Are you sure you understand how type inference works? Because a given expression can be interpreted to be of one and exactly one type. If there was any possible ambiguity, then C++ wouldn't be strongly-typed.

[anonymous23323124]

helios wrote:

absurd case where nearly all locals are auto'd

This is what I was concerned about. I can imagine that programmers new to C++ from a language where all variables are declared in the same way might end up just using auto. That's why I probably won't put it in the tutorial.

My concern was with the user, not the compiler ;)

[z05DSL3A]

Show them the non-auto ways and then show them the auto ways. All good teaching material should show how to do it 'properly' and then show any time saving techniques.

[anonymous23323124]

Yeah; the question is - do I show them the auto way at the end of the variables tutorial (lesson 4), or do I keep it for a much later tutorial all together?

[3hM2Nwbp]

I'd save it for a later tutorial - about the time that you cover decltype

http://en.wikipedia.org/wiki/Decltype

[Veltas]

helios wrote:

I don't see how that relates to Luc Lieber's example. In any case, I'm having a hard time picturing an abuse of auto, beyond the absurd case where nearly all locals are auto'd and the programmer has lost track of all types.

That's exactly what I was worried about. It's too easy for a new programmer to do.

helios wrote:

Are you sure you understand how type inference works? Because a given expression can be interpreted to be of one and exactly one type. If there was any possible ambiguity, then C++ wouldn't be strongly-typed.

I think you misunderstand me, I was comparing the strong C++ type system to the weaker (possible) use of auto, or other languages in general.

Grey Wolf wrote:

Show them the non-auto ways and then show them the auto ways. All good teaching material should show how to do it 'properly' and then show any time saving techniques.

I second the motion.

Luc Lieber wrote:

I'd save it for a later tutorial - about the time that you cover decltype

I second the motion, again.

[helios]

This is what I was concerned about. I can imagine that programmers new to C++ from a language where all variables are declared in the same way might end up just using auto. That's why I probably won't put it in the tutorial.

That's exactly what I was worried about. It's too easy for a new programmer to do.

It's also easy to abuse operator overloading, and the result can be much more cryptic (e.g. guess what x+y does. x and y are templated, the definition of + doesn't use the arithmetic +, and there may be polymorphism around x) than when abusing auto. Is that a reason not to include operator overloading?
Do you know what kind of people leave features out because they can abused? Java designers.

I think you misunderstand me, I was comparing the strong C++ type system to the weaker (possible) use of auto, or other languages in general.

Again, are you sure you understand what type inference is? It's quite different from type coercion, which is what I think you're thinking about. Using auto doesn't necessarily mean that this code will be valid:

auto x=f();
std::string foo="bar"+x;

The code will be valid depending on the type of f(). With type coercion, it will always be valid.

[anonymous23323124]

helios wrote:

Java designers.

Haha ;)

helios wrote:

Is that a reason not to include operator overloading?

No, but operator overloading is not a feature one teaches very early on.

Similarly, I'm not sure whether teaching auto in the same lesson as variables (i.e. lesson 3) is a good idea. To be honest, I would quite like to include it, as it is rather useful, but I am still not convinced it is a good idea to teach it so early.

[helios]

Well, no one said early. Seeing as it's part of a standard that still hasn't been published, I'd leave it for the very end. Possibly an appendix.

[anonymous23323124]

Do you mean at the end of the lesson, or at the end of the whole series?

[S6k9GNh0]

I think auto is a "learn in the hard way" idea. We all know that when we are a kid we love candy. We eat too much of it, we get sick. We don't do it again. Even a newbie would at some point say, "I have no clue what type this variable is. This is getting irritating..." and he'll start using another method to keep track of the types or perhaps his own set of rules on when to use auto and when not to.

(Except for the case where auto is used *everywhere* and then the types are commented to keep track of them. We all know there is going to be a case of this _somewhere_.)

Or am I being to hopeful?

[anonymous23323124]

I'm not sure: I think teaching auto too early might make too much of a mess of people's code - they might not learn their lesson soon enough. Although it's not actually "bad" code so I guess it might not hurt, provided I made the "proper usage" of auto clear.

In particular, in Visual Studio, people might not lose track of types anyway - Intellisense evaluates it all in real time, so when you hover over an auto variable it tells you the actual type. I guess it'll get confused if the code is complex enough...