The Proposed New Purpose for the C++ auto Keyword...
One of the little known keywords of C++ (or even C, at that) is the auto keyword, and however unknown it is, it is the default behaviour for variables. The keyword is one of the three variable storage classes, the other two being extern and static, and means that the variable should be allocated on the stack. In my more than ten years of developing in C and C++, I have seen this keyword used probably twice, neither of which were, by any means, required and caused more confusion than if they were not there.
According to The InformIT C++ Guide, auto for the People discusses how Bjarne Stroustrup and Jaakko Järvi have a proposal for C++0x to reuse this keyword and to add a new one, decltype.
In their proposal, the auto keyword allows the type of a variable to be automatically discovered. For example, consider the following segment:
- std::vector<MyClass> v;
- ...
- for ( auto it = v.begin(), end = v.end(); it != end; ++ it ) {
- ...
The attentive reader will notice that in line 3, the type of the iterator, it, is not declared, and rather is implied as what we would write today: std::vector<MyClass>::iterator.
Danny’s spin on this new purpose for auto appears focused on the number of characters to type (and while the comments on Java may be true, I do not really feel it adds to the article at all), and this is really where my concern is for this feature. I think that code that exploits this behaviour will have maintainability issues. For example, consider the following segment:
- auto v = myFunction();
- for ( auto it = v.begin(), end = v.end(); it != end; ++ it ) {
- ...
Looking at this code, I assume that myFunction returns some type of container that has an iterator, but this is simply an assumption based on how the variable v is used. During the maintenance of code, this return value could change, and this is where I am sure that the errors generated by the compiler can get a little odd, especially if myFunction() is actually in a library, and the developer porting it to the latest version is not the developer who has changed this behaviour. Today if this problem occurred, the error would occur right when you call myFunction(), since there is a type mismatch, but with this new behaviour, the error would probably occur somewhere in the for loop where v is actually used.
Perhaps this example is a bit too simple since we are dealing with the standard library. But consider the situation where the type is not a vector. How do you know what methods to call on this class? Is it even a class? As reminded by Code Reading, we definitely read code more times than we write it; is this typing convenience really worth this ambiguity? I do not think so. There is only one place that I can think of using it, and I will get to that in a moment.
The other keyword, decltype, acquires the type of the variable in question, similar to the non-standard typeof function provided by some compilers. For example, decltype( it ) would acquire the std::vector<MyClass>::iterator, and unfortunately this is as detailed as Danny really gets on this topic.
For developers who have not delved into the world of generic programming, I do not see these features as being useful at all. In the context of generic programming though, both of these keywords will make generic programming easier and far more useful. How many times have you had to add more parameters to your generic algorithm because it used another algorithm whose return value differs? This is a perfect application for the auto keyword. The declaration type also similar benefits, allowing the return value of a generic algorithm to be dependent on some external method, for example.
Of course, this is still a proposal and is not guaranteed to be in the C++0x standard. Nevertheless, I see as a really practical feature for generic programming. But please stay away from using it to save typing!