Why had we used "auto" if we knew type of the objects?

[Bloodrushh]

Hello everyone!
I`v got a qustion.
Why had we used “auto” if we knew type of the objects?
Why we didnt use FHitResult type for Hitresult instead of auto e.t.c.

Thanks.

[QueueButton]

Personally, I put this under each programmers decision (or company decision).

But, technically since you’re working with 3rd party code, perhaps it will be safer by using auto in the event they change the type or some other reason. Probably, though I feel if they change it then there would be other problems instead lol.

Its also shorter to type than FHitResult. Or maybe they just wanted do it for “fun” similar using namespace std.

Generally, in programming there are multiple ways of doing things.

How much is too much with C++11 auto keyword?

But in the end, readability should always come first so if it hurts readability then don’t use it. You should always be able to look at code and instantly know what’s happening. If you can’t do that then it needs improvement. auto can be underused and overused.

[DanM]

It’s a controversial topic in the C++ community.

Herb Sutter proposes “Almost Always Auto” style you can hear his arguments here
https://youtu.be/xnqTKD8uD64?t=1703

And then Nicolai Josuttis proposes “Almost Always Auto Ampersand Ampersand” (lol) for C++20 in which initalisation rules are “fixed” somewhat.

I personally don’t like it. I use auto “where it makes sense”.

• range-for loop variables - the type is clear, whatever the element type is of the thing I’m iterating
• iterators - again, the type is clear, iterator to whatever the thing I’m getting an iterator to

  std::vector<int> vec{ 1, 2, 3 };
  std::vector<int>::iterator iter = vec.begin();
  

  is just needlessly verbose.
• Where it avoids repeating the type

  ATank* Tank = Cast<ATank>(GetPawn()); //ATank twice
  auto Tank = Cast<ATank>(GetPawn());
  

• Lamdas
• In templates where specifying the type would be like the iterator example above.