Hacker News Reader

Comment by nadams | Hacker News Reader

> It's new but is it really bad?

My opinion - yes. I never imagined typing out type names was a hassle when using an IDE like Visual Studio. I know a number of people use it religiously - but when I read code I find it easier to read C++ with types than the auto keyword everywhere. But I'm sure a number of people still use vi (or emacs), and even smaller number of those people use gdb or some other debugger.

Apparently Linus doesn't use a debugger [1]. I have some comments on that - but I'll keep them to myself.

[1] http://www.linuxtoday.com/infrastructure/2000090700221OSCYKN

View on HN

We seem to agree and disagree on a number of things but I was thinking of one specific use of the new syntax as described on SO[1]. Here, I believe that the new syntax is clearly easier to use and consistency can be a good thing. By the way, with this syntax the return type is still spelled out so it shouldn't matter IMO.

[1]: http://stackoverflow.com/a/22515589/862288

Quoting Herb Sutter, "AAA Style (Almost Always Auto)":

"Guideline: Remember that preferring auto variables is motivated primarily by correctness, performance, maintainability, and robustness—and only lastly about typing convenience." [1]

http://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-...

auto variables are different from trailing return types introduced by auto (a particularly egregious appropriation of a keyword for a totally different use).

> a particularly egregious appropriation of a keyword for a totally different use

Which seems to be an often case in C++, class and class/typename comes to my mind. Also, old auto use was removed to the new set of meaning right?

Old auto was completely removed.

> correctness, performance, maintainability, and robustness

What? I want whatever he is smoking.

> correctness

C++ allows for casting to/from different types (the core behind polymorphism) - but if you cast to the wrong type then that's your own fault. If you want a warm fuzzy feeling of not worrying about bad casts - use Python/Go/FreeBASIC/some other language.

> performance

That is complete and utter delusion. Your program won't run any faster or optimize better because you used the auto keyword [1]. If anything - it will take even longer (ms longer) to compile.

> maintainability

I have an odd feeling about that. Yeah you can change the return type of a method or function and you don't have to worry about changing the code calling those methods/functions. But if you are changing to a vastly different type - you are going to have to change the calling code anyways.

> robustness

I don't want the compiler to fix my mistakes. I want the compiler to tell me how stupid I am and force me to fix them.

[1] http://stackoverflow.com/questions/19618759/c-11-auto-compil...

I have an identical complaint. Reading tutorials / books / api examples was dramatically easier before auto came on the scene. Now I have to have the header open on the side while I read api documentation, because most of the time I need the type information to decipher whats being written in the example.

Can you share exactly why? If it is because auto as returning type, the header wouldn't be of much of a help would it?

I find it easier to read now, specially when using iterators on for loops.

Heres an example ->

auto now = boost::chrono::steady_clock::now().time_since_epoch();

auto timeSinceEpoch = boost::chrono::duration_cast<boost::chrono::milliseconds>(now).count();

(This is from http://stackoverflow.com/questions/16700277/get-a-double-fro...).

The person writing the answer is dilligent and hence has supplied the types as a preamble. Most articles / answers / api docs dont take the effort to elaborate on return value types.

Probably you're already aware of this but it might be useful for you or others. Item 4 of Scott Meyers' Effective Modern C++[1] shows you how to get some type information without needing to open the headers yourself.

[1]: http://shop.oreilly.com/product/0636920033707.do

Reply on news.ycombinator.com