4 ms·

C++ 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.

by jobu 12y ago

C++ 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 ago
Then start with Herb Sutter, because that is exactly his advice at the latest CppCon.
- jobu 12y ago
  Yes, 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.
  - swift 12y ago
    The type of h isn't so hard to understand, there. |auto| gives you a value; if you want a reference, use |auto&|. This rule actually makes |auto| more readable: you always know if you're looking at a reference or not. Probably you expected |auto| to behave like |decltype()|, C++11's other form of type deduction, which gives you the actual type of an expression. C++14 adds |decltype(auto)|, which lets you declare local variables using this behavior if you want it. I'm not sure whether I'd apply Herb's AAA rule quite as broadly as he suggests, but I think it's broadly right, because far too often in C++ we write a type twice on the same line, which is just redundant. I vastly prefer |auto val = new MyClass;| to |MyClass val = new MyClass;|, and similarly |auto casted = static_cast<MyType>(uncasted);| is completely readable without typing writing "MyType" a second time. C++ programmers are a conservative lot, but I expect using |auto| at least in those cases to be pretty mainstream within a few years.
crpatino 12y ago
If there is a feature that could be misused, it will be misused. It does not matter what the rationale behind the committee's decision was. This is standard practice in duck typed languages, and it will be adopted as well in C++, since it will be (imho, correctly) perceived as another step to bring C++ "to the 21th century". You can stern-talk as much as you wish... but it won't have much effect unless backed up by an (effectively enforced) internal code style guide. The barbarians are already at the gate. Which side are you going to pick?
- dragonwriter 12y ago
  > This is standard practice in duck typed languages Only because there is no choice in those languages -- and, in those language communities, there's considerable call for finding a good way to include optional explicit and enforced declared typing specifically so that a choice does exist. So, even given that communities that (unlike C++, even with auto existing) accept languages that don't provide an alternative to to the equivalent of "auto everywhere" push back against that practice to the extent of seeking language features to provide an alternative to it, I don't think that auto becoming an option is going to mean auto everywhere takes over C++. There'll probably be some overuse (particularly in a brief period before a widely-accepted conventions on appropriate use are established), but its hardly the most dangerously abusable feature of the C/C++ language family.
- furyofantares 12y ago
  Perhaps I'm lucky, I haven't found internal coding styles to need _any_ enforcement, in my experience people find it inherently valuable.
  - deleted 12y ago
    [deleted]
- quacker 12y ago
  If there is a feature that could be misused, it will be misused. It does not matter what the rationale behind the committee's decision was. This is quite a narrow-minded line of thinking. You're saying "Feature X is should be excluded because of <possible consequence>". But we can say the converse about this same feature: "Feature Y should be included because <possible benefit>". Every programming language feature ever has had its pros and cons, and every language designer makes tradeoffs deciding which features to include and which to exclude.[1] You also most likely overestimate the practical unreadability of the source code. IDEs are (or will be) smart enough to deduce and display the type of an auto declared variable[2] when you want it. For short functions, it will be blindingly obvious what the auto-declared return type of a function is. Using auto will vastly improve readability by reducing textual noise when a function returns (1) heavily templated expressions, (2) any type within a deeply-nested namespace, (3) any type with a long name, or especially (4) combinations of the previous three (e.g. std::vector::const_iterator< std::pair<std::string, double> >). Complicated types are a common issue in languages with static type systems[3]. I could go on. There are tons of use-cases where auto will help out. The biggest complaint I have is that you can auto-declare the return type of methods that return private variables from a class (unless I'm mistaken; I haven't actually tried it). This pokes leaky holes in your class's encapsulation, forming dependencies between external code and your class's private, internal implementation (although this may be possible through template magic...). The barbarians are already at the gate. Which side are you going to pick? Oh, cut the drama. Every language has some sort of a style guide, and C++ programmers are already used to following a style guide and programming with discipline. One more feature with a few downsides and a number of benefits is not going to make a difference, and is totally in line with its philosophy[1]. 1: http://en.wikipedia.org/wiki/C%2B%2B#Philosophy http://en.wikipedia.org/wiki/C%2B%2B#Philosophy 2: http://stackoverflow.com/q/19625115 http://stackoverflow.com/q/19625115 3: https://github.com/rust-lang/rust/issues/10448 https://github.com/rust-lang/rust/issues/10448

by jobu 12y ago

RogerL 12y ago

Then start with Herb Sutter, because that is exactly his advice at the latest CppCon.

jobu 12y ago
Yes, 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.
- swift 12y ago
  The type of h isn't so hard to understand, there. |auto| gives you a value; if you want a reference, use |auto&|. This rule actually makes |auto| more readable: you always know if you're looking at a reference or not. Probably you expected |auto| to behave like |decltype()|, C++11's other form of type deduction, which gives you the actual type of an expression. C++14 adds |decltype(auto)|, which lets you declare local variables using this behavior if you want it. I'm not sure whether I'd apply Herb's AAA rule quite as broadly as he suggests, but I think it's broadly right, because far too often in C++ we write a type twice on the same line, which is just redundant. I vastly prefer |auto val = new MyClass;| to |MyClass val = new MyClass;|, and similarly |auto casted = static_cast<MyType>(uncasted);| is completely readable without typing writing "MyType" a second time. C++ programmers are a conservative lot, but I expect using |auto| at least in those cases to be pretty mainstream within a few years.

crpatino 12y ago

If there is a feature that could be misused, it will be misused. It does not matter what the rationale behind the committee's decision was. This is standard practice in duck typed languages, and it will be adopted as well in C++, since it will be (imho, correctly) perceived as another step to bring C++ "to the 21th century". You can stern-talk as much as you wish... but it won't have much effect unless backed up by an (effectively enforced) internal code style guide. The barbarians are already at the gate. Which side are you going to pick?

dragonwriter 12y ago
> This is standard practice in duck typed languages Only because there is no choice in those languages -- and, in those language communities, there's considerable call for finding a good way to include optional explicit and enforced declared typing specifically so that a choice does exist. So, even given that communities that (unlike C++, even with auto existing) accept languages that don't provide an alternative to to the equivalent of "auto everywhere" push back against that practice to the extent of seeking language features to provide an alternative to it, I don't think that auto becoming an option is going to mean auto everywhere takes over C++. There'll probably be some overuse (particularly in a brief period before a widely-accepted conventions on appropriate use are established), but its hardly the most dangerously abusable feature of the C/C++ language family.
furyofantares 12y ago
Perhaps I'm lucky, I haven't found internal coding styles to need _any_ enforcement, in my experience people find it inherently valuable.
- deleted 12y ago
  [deleted]
quacker 12y ago
If there is a feature that could be misused, it will be misused. It does not matter what the rationale behind the committee's decision was. This is quite a narrow-minded line of thinking. You're saying "Feature X is should be excluded because of <possible consequence>". But we can say the converse about this same feature: "Feature Y should be included because <possible benefit>". Every programming language feature ever has had its pros and cons, and every language designer makes tradeoffs deciding which features to include and which to exclude.[1] You also most likely overestimate the practical unreadability of the source code. IDEs are (or will be) smart enough to deduce and display the type of an auto declared variable[2] when you want it. For short functions, it will be blindingly obvious what the auto-declared return type of a function is. Using auto will vastly improve readability by reducing textual noise when a function returns (1) heavily templated expressions, (2) any type within a deeply-nested namespace, (3) any type with a long name, or especially (4) combinations of the previous three (e.g. std::vector::const_iterator< std::pair<std::string, double> >). Complicated types are a common issue in languages with static type systems[3]. I could go on. There are tons of use-cases where auto will help out. The biggest complaint I have is that you can auto-declare the return type of methods that return private variables from a class (unless I'm mistaken; I haven't actually tried it). This pokes leaky holes in your class's encapsulation, forming dependencies between external code and your class's private, internal implementation (although this may be possible through template magic...). The barbarians are already at the gate. Which side are you going to pick? Oh, cut the drama. Every language has some sort of a style guide, and C++ programmers are already used to following a style guide and programming with discipline. One more feature with a few downsides and a number of benefits is not going to make a difference, and is totally in line with its philosophy[1]. 1: http://en.wikipedia.org/wiki/C%2B%2B#Philosophy http://en.wikipedia.org/wiki/C%2B%2B#Philosophy 2: http://stackoverflow.com/q/19625115 http://stackoverflow.com/q/19625115 3: https://github.com/rust-lang/rust/issues/10448 https://github.com/rust-lang/rust/issues/10448