21–30 of 47 posts
Of the 3 options below, the third seems best to me:
SomeReallyLongTypeName* x = foo(); // old-school
auto x = foo(); // c++11
pointer x = foo(); // c++17 conceptsSo auto allows you to deal more easily with c++ crap, especially STL. My first thing to do in all my c++ project is to import my in-house STL wrapper, which makes STL usable for me. I never understood how people can work with raw STL. I don't like at all working with templates and i am using it only in internal class implementations. C++ without templates is so much more beautiful.
Will best practice for the auto keyword change when c++ concepts finally arrive? Of the 3 options below, the third seems best to me: SomeReallyLongTypeName* x = foo(); // old-school auto x = foo(); // c++11 pointer x = foo(); // c++17 concepts
Will best practice for the auto keyword change when c++ concepts finally arrive? Of the 3 options below, the third seems best to me: SomeReallyLongTypeName* x = foo(); // old-school auto x = foo(); // c++11 pointer x = foo(); // c++17 concepts
you can already do: auto *x = foo(); Which is actually more readable than "pointer".
smart_ptr x = foo();I'd be more than annoyed if I saw someone name a function "xxInteger()" because it returns an integer. I don't actually think the first example was that bad, modulo some context. Sometimes even knowing the type for this kind of thing isn't super important to understand what the code is doing; ala opaque types.
What exactly is annoying? I always want my variable names to be as long and descriptive as possible. We're no longer in the teletype era and our monitors are huge. With autocomplete there is no reason to keep variable names short
No. In Herb Sutter's words, avoiding auto since it makes the code "unreadable": ...reflects a bias to code against implementations, not interfaces. Overcommitting to explicit types makes code less generic and more interdependent, and therefore more brittle and limited. It runs counter to the excellent reasons to “write code against interfaces, not implementations” See http://herbsutter.com/2013/08/12/gotw-94-solution…
Why this dismissive comment? auto is definately overused in ways that are unreadable, exactly like the blog author says. Marking the type explicitely may be less generic in a way, but it helps readability so much by providing redundancy.
The second issue (async) is quite similar in my opinion, and in practice your async handler will be explicitly decoupled and strongly typed at some point for reasons of testability so the example is describing also an OO design issue and not an issue with auto.
There may be real problems with auto but this article did not provide any compelling evidence of them.
Earlier quoted context omitted.
I would be very surprised if someone can meaningfully review C++ templates without an IDE. Really not reviewing a program inside an IDE is a poor idea in general.
Some of us still use emacs and vim.
So auto allows you to deal more easily with c++ crap, especially STL. My first thing to do in all my c++ project is to import my in-house STL wrapper, which makes STL usable for me. I never understood how people can work with raw STL. I don't like at all working with templates and i am using it only in internal class implementations. C++ without templates is so much more beautiful.
Would you mind giving some examples? I don't find STL to be crap at all.
vs
auto it = hashmap.begin();
I find auto useful for cutting down some of the verbosity of templates STL containers, but I can see how over use can lead to code requiring much more referencing if maintaining code that rarely defines types.
I'd be more than annoyed if I saw someone name a function "xxInteger()" because it returns an integer. I don't actually think the first example was that bad, modulo some context. Sometimes even knowing the type for this kind of thing isn't super important to understand what the code is doing; ala opaque types.