4 ms·

It's new but is it really bad? It allows for more uniform code if you're using the new style for decltypes anyway. If I would make heavy use of that construct I

by Bootvis 11y ago

It's new but is it really bad? It allows for more uniform code if you're using the new style for decltypes anyway. If I would make heavy use of that construct I would certainly prefer the definition used in the article.

nadams 11y ago
> 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 http://www.linuxtoday.com/infrastructure/2000090700221OSCYKN
- ingve 11y ago
  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-almost-always-auto/ http://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-...
  - StephanTLavavej 11y ago
    auto variables are different from trailing return types introduced by auto (a particularly egregious appropriation of a keyword for a totally different use).
    - pmelendez 11y ago
      > 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?
      - StephanTLavavej 11y ago
        Old auto was completely removed.
  - nadams 11y ago
    > 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-compile-time-or-runtime http://stackoverflow.com/questions/19618759/c-11-auto-compil...
- dman 11y ago
  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.
  - pmelendez 11y ago
    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.
    - dman 11y ago
      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-from-boostchronosteady-clocknow 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.
  - Bootvis 11y ago
    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 http://shop.oreilly.com/product/0636920033707.do
- Bootvis 11y ago
  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 http://stackoverflow.com/a/22515589/862288

by Bootvis 11y ago

nadams 11y ago

> 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 http://www.linuxtoday.com/infrastructure/2000090700221OSCYKN

ingve 11y ago
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-almost-always-auto/ http://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-...
- StephanTLavavej 11y ago
  auto variables are different from trailing return types introduced by auto (a particularly egregious appropriation of a keyword for a totally different use).
  - pmelendez 11y ago
    > 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?
    - StephanTLavavej 11y ago
      Old auto was completely removed.
- nadams 11y ago
  > 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-compile-time-or-runtime http://stackoverflow.com/questions/19618759/c-11-auto-compil...
dman 11y ago
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.
- pmelendez 11y ago
  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.
  - dman 11y ago
    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-from-boostchronosteady-clocknow 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.
- Bootvis 11y ago
  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 http://shop.oreilly.com/product/0636920033707.do
Bootvis 11y ago
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 http://stackoverflow.com/a/22515589/862288