
Don’t use C++ auto? Restricting auto is not the best decision - etrevino
http://swdevmastery.com/dont-use-c-auto-restricting-auto-is-not-the-best-decision-for-your-company-and-it-is-unfair-to-your-developers-instead-train-them-on-how-to-use-it/
======
raverbashing
This shouldn't even be up to discussion. Auto _is better_ overall

Compilers know types better than humans.

Whoever bans it (whithout a very, very compelling reason like "some of our
code has to compile in an old compiler") is being a luddite at best.

This should have been in C++ from its inception to be honest, to avoid
blah_type<with_this> something = new blah_type<with_this>() repetition.

~~~
pjmlp
> This should have been in C++ from its inception to be honest

It was, but the backslash was even greater back then, so Bjarne removed it
from _C with Classes_.

There are a few presentations/interviews where he mentions it.

~~~
cjensen
That was an entirely different auto. In C89, auto just "variable on the
stack". It still had a type. The new auto is just borrowing the keyword since
it (a) makes sense and (b) is already a reserved word.

~~~
pjmlp
How the keyword was named when Bjarne introduced it doesn't matter, the
purpose was the same as C++11 auto.

~~~
Shorel
It was entirely another concept.

Before C++11 auto meant it was not static, extern or register, and in fact
every single variable was already implicitly auto if no specifier from the
previous list was applied.

    
    
        int n = 10;
    

In that line, n was auto. Now it is not auto, only int.

~~~
pjmlp
Type inference is orthogonal to whatever keyword is used.

Bjarne used another keyword in _C with Classes_ , removed it due to backslash,
and the commite decided to re-purpose _auto_ for the same purpose in C++11.

No big deal, the meaning of _static_ is also context dependent, and no one is
fighting against it like it happens with the new meaning for auto.

------
Asooka
My rule of thumb is "the type has to be stated clearly and unambiguously at
least once on the line the variable is declared.

Yes:

    
    
      auto foo = new Foo(bar);
    

Maybe:

    
    
      auto foo = FooFactory::newFromBar(bar);
    

No:

    
    
      auto foo = bar(baz);

~~~
symlinkk
Any decent IDE should be able to tell you the type by hovering your mouse over
the variable, even if it's made with auto.

~~~
quickben
Yeah, but that's corner case. We usually read code on screens, paper, email,
git history, etc.

------
maxxxxx
And I thought auto was the best thing ever to happen to C++? Especially when
working with STL.

~~~
gambiting
My problem with auto is that Visual Studio loses all ability to predict code
when you use it. So when I do Type object and then do object. I get all the
methods/members available for that Type. But if I use auto, VS is either can't
recommend anything or recommends the wrong set of methods entirely. It really
slows me down as a programmer and I hate using it for that reason.

~~~
zvrba
It worked fine in VS2015 and works fine in VS2017. It doesn't work in cases
where it _cannot_ work, as in

``` template<typename T> void f(const T& t) { auto val = t.some_method(); }
```

and here it cannot work because T can be an arbitrary type and there's simply
not enough info for intellisense to work and suggest members on val.

~~~
trendia
Qt Creator handles this problem differently. If you call f<int>(0) and
f<uchar>(0) within your code, then the Clang code model will process both in
the background, check for any syntax errors, and show an error if either one
fails.

It's very useful while coding because you don't have to wait until compilation
time to see an error, and it's a feature I wish VS would implement.

------
vanderZwan
So this is a bit of a tangent, but Julia has this ability to use their typing
system in such a way that lets you restrict what subtypes are allowed to be
assigned to a variable (I'm just using Julia as an example because that is
where I first saw this, I'm sure it originated from Scala or something; I'm
not a CompSci historian). So if we have these abstract types:

    
    
        abstract type Number end
        abstract type Real     <: Number end
        abstract type AbstractFloat <: Real end
        abstract type Integer  <: Real end
        abstract type Signed   <: Integer end
        abstract type Unsigned <: Integer end
    

... then I can make a function that takes any value as long as it's a subtype
of Number, which implies I can do addition and subtraction and all the other
things all numbers can do. So I still have the type safety of not ending up
with an object where I want a number, but it is still extremely easy to write
generics in Julia[0].

Can you do something like that in C++? So like:

    
    
        auto <: SomeBaseClass
    

Meaning _auto_ would work just like it normally does, except that if you
assign something that is not derived from SomeBaseClass the compiler
complains, giving you some extra safety checks when composing code with _auto_
all over the place.

[0]
[https://docs.julialang.org/en/stable/manual/types/](https://docs.julialang.org/en/stable/manual/types/)

~~~
davidcuddeback
If you're curious, that feature is called bounded polymorphism [1]. It's
supported by Java and Rust, too, and I'm sure other languages as well. As
mattnewport said, something similar is in the works for C++.

[1]
[http://wiki.c2.com/?BoundedPolymorphism](http://wiki.c2.com/?BoundedPolymorphism)

~~~
vanderZwan
Thanks, now I know what to search for next time :)

------
tzahola
Hm. I thought using _auto_ was the recommended, modern way of writing C++.

~~~
ska
It is.

Some people don't want to learn how it works, and have been bitten by
unexpected results. Like nearly everything in c++, there are some odd corner
cases.

However, auto is a big net win. You should understand it, and you should use
it.

~~~
ChrisSD
> However, auto is a big net win. You should understand it, and you should use
> it.

Which is a fair summary of the linked article.

------
dogruck
The title is misleading. It starts with that argument as a preamble, but the
bulk of the content is a detailed technical explanation for how “auto” works
in C++.

I was expecting some style guide rules of thumb.

Scott Meyers does a good job of explaining “auto” in Effective Modern C++.

~~~
mannykannot
Rules of thumb work a lot better, and are often easier to explain and
remember, if you understand their rationale.

~~~
dogruck
I completely agree with you. I just think the linked article could be
strengthened by adding some rules of thumb. No complaints about its technical
explanation.

~~~
mannykannot
I see what you mean - those rules don't help with writing code.

------
Dylan16807
> At this point, you are probably thinking: “Holy cow! All these rules, and he
> is not even done with Use Case 1!”

No, I'm thinking "Holy cow! He used so many words to explain such simple
behavior!"

The initializer list rule seems like a bad idea, at least.

------
Koshkin
'auto' is a terrible choice of the keyword. 'var', like in C#, would be much,
much better. But no, the C/C++ people have been bitten by this weird keyword
overload bug - the same one that caused 'static' to also mean "local"...

~~~
nightcracker
The issue is that 'var' would make old code not compile anymore, while 'auto'
was already a keyword with pretty much no use.

~~~
Koshkin
The change of the meaning of 'auto' already broke the old code. In C, 'auto'
is used to specify a storage class; in C++, it stands for the _type_. So, the
valid C code

    
    
      auto float x;
    

when compiled with a C++ compiler, produces an error message.

~~~
beojan
If we're talking about _actual C++_ code, auto is a reserved keyword (so it
wouldn't be used as an identifier) but it was useless, so it wouldn't be used
as a keyword in any real (C++) code.

------
millstone
auto can be ambiguous:

    
    
       template<typename Collection>
       void foo(const Collection &c) {
         auto x = c.find("foo");
         ...
       }
    

is x an iterator (Collection is std::map) or a number (Collection is
std::string)? Here it is better to write out the iterator type if that's what
you mean.

auto can also be downright misleading:

    
    
       template<typename T>
       void foo(std::vector<T> &c) {
         auto first = c[0];
         ...
       }
    

`first` has type T except when T is bool. Gross. Better to write out the type
T.

auto can simplify many cases, but please don't take Sutter's "almost always
auto" suggestion. Keep your future code readers in mind and be aware of its
pitfalls.

~~~
smitherfield
> _is x an iterator (Collection is std::map) or a number (Collection is
> std::string)? Here it is better to write out the iterator type if that 's
> what you mean._

The reader would be able to infer this from context (as is the compiler, so
it's still type-safe).

> _`first` has type T except when T is bool. Gross. Better to write out the
> type T._

That's a preexisting problem with `vector<bool>` much more than it is with
`auto`.

------
TACIXAT
Auto is nice to use, but I absolutely hate getting up to speed on a code base
that uses it.

~~~
mattnewport
This suggests you need a better IDE.

~~~
TACIXAT
You are correct. I work in Sublime Text.

------
jwilk
What a terrible title.

My poor monkey brain couldn't cope with the amount of negation, and thought
it's a criticism of "auto".

------
bitL
'auto' makes it difficult to predict what type you actually need for a new
method that uses some parameter you get from a 3rd party library. I once had
like 12 nested templates revealed to me only during debugging with RTTI as a
type of some innocent auto parameter.

~~~
roel_v
"Effective Modern C++" (Scott Meyer) has a chapter on how to tease deduced
types out of compilers. You can argue "it's silly that I even have to do
that", and yes I'd argue that too, but sometimes you just need auto inside
templates. Before I started using it, I thought it'd be a train wreck, but now
I quite like it - when used judiciously.

I do find myself writing code with auto, then when I revisit it at some point,
replace it with the explicit type for readability. But that's only for a small
percentage of the cases where I use auto, so overall it's a net plus.

~~~
AnimalMuppet
> ... when used judiciously.

That applies to many C++ features, not just auto.

Maybe the problem with C++ is that it's not a language that you can use well
without developing a sense of good taste - knowing _when_ to use certain
things, and when not to. (And then you have to interface with code written by
someone else who didn't have any taste, and just used features without regard
to whether they made things better or worse...)

~~~
roel_v
Pff, is that a problem with C++ or with programming in general? There is not a
single language in the world you can use well without developing a sense of
good taste. And what is good taste not only differs between languages (for the
exact same concept, like how do you sum the values of an array, or how do you
execute two code paths in parallel), but also changes over time.

------
Kenji
I never use auto in C++, except for when I have very complicated (or
impossible to define) types like lambdas. I want complete clarity about what
types I am using.

------
jkforpres
If you're still using c++ in 2017, you're already doomed. While I understand
not everyone is pro enough to translate old rotting code to Rust and other
superior languages, you still can make your contribution to humanity by
writing new projects in better languages. For how many upcoming years will you
fool yourself writing in shitty languages and calling yourself programmers
while inflicting pain upon next generation of programmers lol.

~~~
erikbye
Yes, because C++ isn't good enough to handle complex projects that require
performance AND safety, few bugs. Like the whole F-35 platform. Hardly old and
rotting. If you know what you're doing you can write safe and performant code
using this language. I'll let you know though, it's a trick not that many
people know how to perform, and it's not a fault of the language, but bias and
misconception. But sure, for the next JSF program, let's just try something
new and immature.

It's weird how people can't fathom that we're not all using their favorite
language for real-time, safety-critical systems. Don't you think it's with
good reason? That, in billion-dollar projects, all options have been
considered? Everyone is using C and C++ for this purpose. From BAE to JPL.

~~~
pjmlp
Large scale projects aren't always about technology.

Hiring process, politics and developer salaries also play a big role.

~~~
erikbye
Doesn't change the fact that no other language than C and C++ can be used for
these systems. Same for complex and demanding video games, which has a lot of
the same requirements and characteristics as safety-critical real-time
systems. Plenty of game devs dislike C++, but right now, nothing else is
feasible. One of these devs is Jon Blow, who's apparently so fed up with the
language that he's put a lot of effort into one of his own. Several big
industries use C and C++ because there is no other viable option. One day,
other languages might be, but that day is not here.

Go ask the Rust or D guys if their language and tools are ready to replace C++
for the F-35 project.

~~~
pjmlp
Ada, SPARK and Real Time Java are used on those systems as well.

Regarding games, most AAA game engines are hybrid, with C++, C and Assembly
only being used for the graphics and audio processing core.

Everything else on the engine is a mixture of D, C#, Blueprints, Lua, Python,
Flash, Lisp, in-house scripting language, depending on the studio.

~~~
erikbye
Ada usage has declined a lot. F-35 is primarily C++, Ada percentage is meager,
and I haven't even heard it confirmed that Java is used for anything critical,
but I wouldn't be surprised if it's used for some ground control stuff. NASA
uses Javascript for a lot of their non-critical systems. Ada was highly
specialized, and its use came with strict requirements (e.g., processor type)
that have made it difficult to continue its use, not to mention lack of
knowledgeable developers. In another turn, less strict DoD requirements have
made it easier to use other languages. It's been quite a few years since Ada
saw heavy usage in DoD projects, though it still has relevance. The legacy
code base is huge.

I never meant to imply that games are comprised of only C++. Of course, you
are right: a game and its tooling consist of several languages. Unreal
Engine's build system is C#--but as you say, the core systems which makes sure
everything's executed in time, rendering, physics, audio, are C, C++ with a
bit of assembly.

And look at what Unity has to do with IL2CPP to increase performance. Unity
has terrible performance because of Mono, but their work on the compiler and
job system should start to pay off. In the case of Unreal Engine, you gain a
lot of performance by using C++ instead of Blueprints. Even so, Blueprints
already compile to bytecode and is ran in a VM and from there they call native
C++ functions, they're not interpreted as is. Not that that has much relevance
to what we're talking about, perhaps, but it does show that making a system
like Blueprints is a significant performance compromise you always try to make
up for. Epic recommends you use Blueprint Nativization (generating native code
from your BPs) for increased performance, and just use C++ outright for heavy
lifting parts. It's not without reason that Epic decided to drop UnrealScript
and just use C++ as their scripting language, as well.

This comment came to be about Unreal Engine. I don't want to detract from
Blueprints though; they're great at what they do. And not to be thought of as
just visual scripting for people who can't program or something for only your
artists/designers to use. A mistaken thinking many seem to share. It's best to
use a combination of the two for easy gameplay scripting and iteration. Just
write C++ and expose it to your BPs.

