I really like C++ (I know, shoot me), and I think auto should be avoided at (almost) all costs.
One of the things I love about a language like C++ is that I can take one glance at the code and immediately know what types I’m working with. auto takes that away while adding almost no benefit outside of a little convenience while writing.
If I’m working with some very big template type that I don’t want to write out, 99/100 times I’ll just have a using somewhere to make it more concise. Hell, I’ll have using vectord = std::vector<double> if I’m using a lot of them, because I think it makes the code more readable. Just don’t throw auto at me.
Of course, the worst thing ever (which I’ve seen far too often) is the use of auto in examples in documentation. Fucking hell! I’m reading the docs because I don’t know the library well! When you first bother to write examples, at least let me know the return type without needing to dig through your source code!
However, my impression is that he’s largely using the existence of templates and polymorphism as arguments that “we don’t really care about type”. I disagree: A template is essentially a generic type description that says something about what types are acceptable. When working with something polymorphic, I’ll prefer ParentClass&, to indicate what kind of interface I’m working with.
Sure, it can be very useful to hide exact type information in order to generalise the code, but I think that’s a weak argument for hiding all type information by default, which is what auto does.
Similarly, what would you gain by saying uint32_t const* x = my_var.get<uint32_t>();
To be frank: You gain the information that MyConcreteType::get<uint32_t> returns a uint32_t, which I otherwise couldn’t infer from the docs. Of course, I could assume it, based on the template parameter, but I don’t want to go around assuming a bunch of stuff in order to read docs.
Take an example like auto x = my_var.to_reduced_form(), it’s very clear that x is the “reduced form” of my_var, which could be meaningful in itself, but what type is it? I need to know that if I want to do anything with x. Can I do x += 1? If I do, will that modify my_var? Let’s say I want to make a vector of whatever to_reduced_form returns… and so on.
All these questions are very easily answered by MyConcreteTypex= my_var.to_reduced_form(). Now I immediately know that everything I can do with my_var, I can also do with x. This makes me happy, because I need to do less digging, and the code becomes clearer to read.
I really like C++ (I know, shoot me), and I think
auto
should be avoided at (almost) all costs.One of the things I love about a language like C++ is that I can take one glance at the code and immediately know what types I’m working with.
auto
takes that away while adding almost no benefit outside of a little convenience while writing.If I’m working with some very big template type that I don’t want to write out, 99/100 times I’ll just have a
using
somewhere to make it more concise. Hell, I’ll haveusing vectord = std::vector<double>
if I’m using a lot of them, because I think it makes the code more readable. Just don’t throwauto
at me.Of course, the worst thing ever (which I’ve seen far too often) is the use of
auto
in examples in documentation. Fucking hell! I’m reading the docs because I don’t know the library well! When you first bother to write examples, at least let me know the return type without needing to dig through your source code!https://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/
Thanks, that was a good read :)
However, my impression is that he’s largely using the existence of templates and polymorphism as arguments that “we don’t really care about type”. I disagree: A template is essentially a generic type description that says something about what types are acceptable. When working with something polymorphic, I’ll prefer
ParentClass&
, to indicate what kind of interface I’m working with.Sure, it can be very useful to hide exact type information in order to generalise the code, but I think that’s a weak argument for hiding all type information by default, which is what
auto
does.deleted by creator
To be frank: You gain the information that
MyConcreteType::get<uint32_t>
returns auint32_t
, which I otherwise couldn’t infer from the docs. Of course, I could assume it, based on the template parameter, but I don’t want to go around assuming a bunch of stuff in order to read docs.Take an example like
auto x = my_var.to_reduced_form()
, it’s very clear thatx
is the “reduced form” ofmy_var
, which could be meaningful in itself, but what type is it? I need to know that if I want to do anything withx
. Can I dox += 1
? If I do, will that modifymy_var
? Let’s say I want to make avector
of whateverto_reduced_form
returns… and so on.All these questions are very easily answered by
MyConcreteType x = my_var.to_reduced_form()
. Now I immediately know that everything I can do withmy_var
, I can also do withx
. This makes me happy, because I need to do less digging, and the code becomes clearer to read.deleted by creator