sebastiansylvan

Open full view…

On using 'auto' and 'var' // A Random Walk Through Geek-Space

Fri, 28 Jul 2017 16:16:36 GMT

alter_ego
Fri, 28 Jul 2017 16:16:36 GMT

That's a weird conclusion that people are afraid of "auto" because it's unfamiliar to them. The thing that "auto" does is goddamn simple, you don't have to be a brainiac to understand how type is deduced. It all depends on whether you spend more time reading or writing the code. If you spend more time reading the code, you don't like to jump to function/variable declarations too often. You want the current block of code to be as descriptive as it can be, instead of jumping and trying to figure out what every function within the scope returns. Stating the type directly in a code is not such a big deal, unless you lazy enough to type extra characters. You're right, both of your examples will require a person who reads the code to jump to figure out what the type of "name" variable is. Although in the first case one is enforced to check variable type, but in the second case it's a responsibility of the developer who wrote the code to provide highly readable and maintainable sources.

ssylvan
Thu, 19 Oct 2017 21:31:49 GMT

The argument for "auto" isn't that you are prepared to sacrifice readability due to laziness, it's that auto improves readability by omitting useless details when possible (much like you do when you extract pieces into helper functions). In other words, if you spend most of your time reading code, you should prioritize making it readable. That means using "auto" on occasion to reduce clutter and keep the code easier to follow.

alter_ego
Fri, 20 Oct 2017 13:33:07 GMT

I'd like to see an example of such usage. I can imagine a few context when auto is crucial, like this: auto data = std::make_shared<DataType>(p1, p2, p3); auto data = new DataType(p1, p2, p3); for (auto cur : values) Apart from these ones, it's hard for me to think of a real good usage that wouldn't sacrifice readability. Although I know one use-case when auto can actually harm: auto v = obj.GetProperty(); Often what you really need is this: const auto& v = obj.GetProperty(); And it's easy to forgot to const ref an auto variable, because the reality dictates that even though you try to omit useless details, you have to understand them fully, you have to spend your time and figure out what the deducted auto type would be, or you risking to get yourself into a trouble. Apart from that, I ran across another issue on my project - we were using "auto" with integers, and because we didn't specify types explicitly, we got signed/unsigned cast which had broken our -1 val ue. I don't remember the exact problem, I only remember that if we specified types explicitly, we could've easily detect that issue in source code (I guess even before committing to a repo).

alter_ego
Fri, 20 Oct 2017 13:38:18 GMT

C# "var" is slightly better than C++ "auto". I'd say it's necessary in a context of creating a new variable like this: var obj = new ObjectType(); There are no readability profits for specifying ObjectType twice,

ssylvan
Fri, 20 Oct 2017 16:56:31 GMT

It's really the exact same argument which lets you omit *both* the type and name in other instances (e.g. "ProcessFoo(GetFoo())"). Sometimes being more explicit doesn't help, it just clutters things up. Again, "auto" is the *in between* option. It's less extreme than what we all already do all the time so it's inconsistent to be on a war path against that unless you also think that we should never be allowed to use temporaries at all. Eg. how about int w = x + y + z, is that ok? Or do we need to do int w = x+y; int w2 = w + z in order to be maximally explicit? Obviously that's silly. We already make judgement calls on omitting useless explicit information all the time, auto is no different.

alter_ego
Fri, 20 Oct 2017 19:04:58 GMT

Okay, first of all, that a nice trick to form an erroneous statement and claim that according to my logic it should be true, but it doesn't really, that's why my reasoning flaws. Regarding your example where w = x + y + z is split into w = x + y; w2 = w + z; - I doubt that auto is typically used in such cases, but let's talk about that. Let's assume we're having this code: void func(int x, int y, int z) { auto w = x + y; auto w2 = y + z; return w2; } Okay, function is small, types above are pretty noticeable. There's nothing wrong in using auto here. Now, let's look at the difference between these two code snippets: func(w.GetObject()); and auto obj = w.GetObject(); func(obj); If obj is not a lightweight class, you're might be wasting your CPU, because what you really want to do here is: const auto& obj = w.GetObject(); func(obj); Temporaries don't have such flaw - they are always optimized. Auto, on the other hand, is a bit misleading, because it's not obvious what the type is, and it's easy to forget how auto is deduced in this context. Does auto helps? Not really - you may fail to notice a problem. Does it hides your type? Yes, an in this context that actually makes it easier to overlook a mistake.