Usually codebases disallow auto because without an IDE it's difficult to see the type. I think this reduces the cognitive load of C++ a bit. The only time it is allowed is getting iterators types from STL containers.
I remember fretting about these rules when reading Scott Meyer's Effective C++11, and then later to realize it's better not to use auto at all. Explicit types are good types
Hard disagree. There are times when nobody, really nobody, cares about a given type. See the example of std::chrono::steady_clock::now over at cppreference.com. There you have
const auto start = std::chrono::steady_clock::now();
do_some_work(size);
const auto end = std::chrono::steady_clock::now();
const std::chrono::duration<double> diff = end - start;
std::cout << "diff = " << diff << "; size = " << size << '\n';
Looking up the (current standard's) return type of std::chrono::steady_clock::now() and spelling it out would serve no purpose here.
With 'auto' it is so very verbose. It can be shorter. Let us put "using TP = std::chrono::steady_clock::time_point;" in some header file to be used in many places. Now you can write
TP start = TP::clock::now();
do_some_work(size);
TP end = TP::clock::now();
I prefer to put the `using` in the block where you need the std::chrono code, which keeps it local and tidy. Putting it in a header is declaring a global type and asking for trouble; at least bound it in a namespace or a class.
> Usually codebases disallow auto because without an IDE it's difficult to see the type. I think this reduces the cognitive load of C++ a bit. The only time it is allowed is getting iterators types from STL containers.
Strong agree here. It's not just because it reduces cognitive load, it's because explicit types allows and requires the compiler to check your work.
Even if this isn't a problem when the code is first written, it's a nice safety belt for when someone does a refactor 6-12 months (or even 5+ years) down the road that changes a type. With auto, in the best case you might end up with 100+ lines of unintelligible error messages. In the worst case the compiler just trudges on and you have some subtle semantic breakage that takes weeks or months to chase down.
The only exceptions I like are iterators (whose types are a pita in C++), and lambda types, where you sometimes don't have any other good options because you can't afford the dynamic dispatch of std::function.
I know Google’s styleguide discourages auto, but other C++ places I’ve worked weren’t scared of it. The type deduction rules usually do what I expect, unless I have a weird pre-C++11 proxy type that somehow hasn’t been updated in the last 14 years.
I agree that auto should be used as little as possible. There are good uses, though. It is okay to use when the type is trivially inferred from the code. What is auto in "auto ptr = std::make_shared<MyNiceType>();". Everybody who knows any C++ knows. Also, lambdas do not have a type that can be written down, so it is okay to use auto for them.
I also prefer not to use auto when getting iterators from STL containers. Often I use a typedef for most STL containers that I use. The one can write MyNiceContainerType::iterator.
Pre LLM agents, a trick that I used was to type in
auto var = FunctionCall(...);
Then, in the IDE, hover over auto to show what the actual type is, and then replace auto with that type. Useful when the type is complicated, or is in some nested namespace.
This makes things seem more complicated than they already are, I feel?
There's nothing special about auto here. It deduces the same type as a template parameter, with the same collapsing rules.
decltype(auto) is a different beast and it's much more confusing. It means, more or less, "preserve the type of the expression, unless given a simple identifier, in which case use the type of the identifier."
I always try to avoid auto in c++ or var in C#. On the paper it is a nice was to save you from typing out the type but this is only true if you have tool support and can use your mouse to obtain the type. In printouts or even in a text snippet I’m am lost. I think auto inC++ was the try to shorten some overburden type constructs and make it a little more friendly to use heavy templating. Please forgive my bad English. I’m no native speaker
Right, although I would argue the most interesting part of the type here is the container, not the containee.
With good naming it should be pretty obvious it's a Foo, and then either you know the type by heart, or will need to look up the definition anyway.
With standard containers, you can have the assumption that everyone knows the type, at least high level. So knowing whether it's a list, a vector, a stack, a map or a multimap, ... is pretty useful and avoid a lookup.
an interesting demarcation of subjective mental encapsulation ... associating the anonymous type of a buffer with the buffer's name ... as opposed to explicitly specifying the type of an anonymously named buffer
I came to like auto over the years, although I also use it sparingly.
Sometimes the concrete types only add visual noise and not much helpful information, e.g. iterators:
auto it = some_container.begin();
Not even once have I wished to know the actual type of the iterator.
It’s extremely convenient for certain things. For example, let’s say I’m referring to an enum constant field of a deeply-nested type. This can easily be expressed as “auto k = a.b.c.d.kind” instead of “Alpha::Bet::Charlie::Delta::Kinds k = a.b.c.d.kind”. It should be used sparingly in local contexts where the meaning cannot be confusing.
I think IDEs are a moving target. Do you consider syntax highlighting to make something an IDE? Macro expansion? Autocomplete? intellisense-like based on full text search? based on a parser? based on the compiler? Is Kate an editor or an IDE? It has LSP support.
Having syntax highlighting makes me slightly faster, but I want to still be able to understand things, when looking at a diff or working over SSH and using cat.
Very much true. On the other hand web based review interfaces seem to be stuck in the '60, when they could be so much better if they properly integrated with the compiler.
This is indeed exactly correct. Probably on its own this is the most important reason for most people to use it, as I think most of the millions of C++ developers in the world (and yes there are apparently millions) are not messing with compiler flags to get the checks that probably should be there by default anyway. The keyword auto gives you that.
I knew the answer to most of these intuitively but the story isn’t great. Regardless of the programming language, I’ve always been an “auto” minimalist. There are relatively few contexts where relying on inference is justified by the expedience. Ignoring the issues raises by the article, explicitness simplifies things and reduces bugs.
That said, there are some contexts in which “auto” definitely improves the situation.
You will typically find bugs go up when you do not use auto in most average C++ code bases because, as noted by another comment, a lot of C++ developers have the bad habit of writing uninitialized variables, which auto prevents.
As a C developer to me uninitialized variables are a feature and I love to invoke UB with __builtin_unreachable, because it makes the compiler able to actually bark at me on incorrect usage instead of it silently working.
The last time I worked meaningfully with C++ was back in 2013. Now that I write mostly Rust and TypeScript, I'm amazed by how C++ has changed over the years!
Regarding the "auto" in C++, and technically in any language, it seems conceptually wrong. The ONLY use-case I can imagine is when the type name is long, and you don't want to type it manually, or the abstractions went beyond your control, which again I don't think is a scalable approach.
Type inference is actually very useful you just need to have the right amount, too little and most of your time is spent on bureaucracy, too much and the software is incomprehensible.
In both Rust and C++ we need this because we have unnameable types, so if their type can't be inferred (in C++ deduced) we can't use these types at all.
In both languages all the lambdas are unnameable and in Rust all the functions are too (C++ doesn't have a type for functions themselves only for function pointers and we can name a function pointer type in either language)
Another place where auto can be useful is to handle cases where the function signature changes without making changes at the calling site. An explicitly typed var would need changing or worse, can work with some potential hidden bugs due to implicit type conversion.
Those are function pointers. Your parent was referring to the function type. Per ISO/IEC 9899:TC3:
A function type describes a function with specified return type. A function type is characterized by its return type and the number and types of its parameters. A function type is said to be derived from its return type, and if its return type is T , the function type is sometimes called ‘‘function returning T’’. The construction of a function type from a return type is called ‘‘function type derivation’’.
I regularly use that in C, to make sure a function matches an abstract interface. Sure, that often ends up in a function pointer, but not always and when I declare the type signature, it isn't yet a function pointer.
> but not define
I think that is because the type signature only contains the types, but no parameter names, which are required for a definition. This is arbitrary, since for data types, the member names are part of the type. It sounds totally fixable, but then you either have two types of function types, one where all parameter names are qualified and one where they aren't and only could use the former for function definitions. Or you would make names also mandatory for function declarations.
> It sounds totally fixable, but then you either have two types of function types, one where all parameter names are qualified and one where they aren't and only could use the former for function definitions
Making the names part of the type would be a bit weird, although we have seen stranger things. The biggest problem is that it would be a breaking change at least in C++.
v is double& in your example, not double. But it's not obvious that omitting the & causes a copy. If you see "for (auto v : vec)" looks good right? But if vec contains eg long strings, you've now murdered your perf because you're copying them out of the array instead of grabbing refs. Yes, you could make the same mistake without auto, but it's easier to notice. It's easy to forget (or not notice) that auto will not resolve to a reference in this case, because using a reference is "obviously what I want here", and the name of the feature is "auto" after all - "surely it will figure it out, right?"
Wow I really thought this would be a compile error. The implicit cast here really is a footgun. Looks like '-Wrange-loop-construct' (included in -Wall) does catch it:
> warning: loop variable 'v' of type 'const std::pair<std::__cxx11::basic_string<char>, int>&' binds to a temporary constructed from type 'std::pair<const std::__cxx11::basic_string<char>, int>' [-Wrange-loop-construct]
11 | for (const std::pair<std::string, int>& v: m) {
Why is this a perf footgun? As someone who doesn't write a lot of c++, I don't see anything intuitively wrong.
Is it that iterating over map yields something other than `std::pair`, but which can be converted to `std::pair` (with nontrivial cost) and that result is bound by reference?
It is not a cast. std::pair<const std::string, ...> and std::pair<std::string,...> are different types, although there is an implicit conversion. So a temporary is implicitly created and bound to the const reference. So not only there is a copy, you have a reference to an object that is destroyed at end of scope when you might expect it to live further.
Each entry in the map will be copied. In C++, const T& is allowed to bind to a temporary object (whose lifetime will be extended). So a new pair is implicitly constructed, and the reference binds to this object.
It's a foot gun. Why is the default target for this gun my foot? "You should be careful to choose the target properly" isn't an answer to that question.
In what way it is a footgun? auto x = ... ; does what I would expect. Copying is usually the default in C++ and that's what I would expect to happen here.
If auto deduced reference types transparently, it would actually be more dangerous.
C++ has value semantics, which means that values of user-defined types generally behave like values of built-in types. In this sense, copying is the only logical default. It's just how the language has been designed.
Things are different in Rust because of lifetimes and destructive moves. In this context, copying would be a bad default indeed.
> because who said that's even achievable, let alone cheap?
Nobody said that. The thing is that user-defined types can be anything from tiny and cheap to huge and expensive. A language has to pick one default and be consistent. You can complain one way or the other.
Auto has really made c++ unapproachable to me. It's hard enough to reason about anything templated, and now I frequently see code where every method returns auto. How is any one supposed to do a code review without loading the patch into their IDE?
I'd suppose this really depends on how you are developing your codebase but most code should probably be using a trailing return type or using an auto (or template) return type with a concept/requires constraint on the return type.
For any seriously templated or metaprogrammed code nowadays a concept/requires is going to make it a lot more obvious what your code is actually doing and give you actually useful errors in the event someone is misusing your code.
1) consistency, 2) scoping is different and can make it a significant difference.
I have been programming in C++ for 25 years, so I'm so used to the original syntax that I don't default to auto ... ->, but I will definitely use it when it helps simplify some complex signatures.
Generally, you don't. I'm not sure why the parent suggested you should normally do this. However, there are occasional specific situations in which it's helpful, and that's when you use it.
1. Consistency across the board (places where it's required for metaprogramming, lambdas, etc). And as a nicety it forces function/method names to be aligned instead of having variable character counts for the return type before the names. IMHO it makes skimming code easier.
2. It's required for certain metaprogramming situations and it makes other situations an order of magnitude nicer. Nowadays you can just say `auto foo()` but if you can constrain the type either in that trailing return or in a requires clause, it makes reading code a lot easier.
3. The big one for everyday users is that trailing return type includes a lot of extra name resolution in the scope. So for example if the function is a member function/method, the class scope is automatically included so that you can just write `auto Foo::Bar() -> Baz {}` instead of `Foo::Baz Foo::Bar() {}`.
1. You're simply not going to achieve consistency across the board, because even if you dictate this by fiat, your dependencies won't be like this. The issue of the function name being hard to spot is easier to fix with tooling (just tell your editor to color them or make them bold or something). OTOH, it's not so nice to be unable to tell at a glance if the function return type is deduced or not, or what it even is in the first place.
2. It's incredibly rare for it to be required. It's not like 10% of the time, it's more like < 0.1% of the time. Just look at how many functions are in your code and how many of them actually can't be written without a trailing return type. You don't change habits to fit the tiny minority of your code.
3. This is probably the best reason to use it and the most subjective, but still not a particularly compelling argument for doing this everywhere, given how much it diverges from existing practice. And the downside is the scope also includes function parameters, which means people will refer to parameters in the return type much more than warranted, which is decidedly not always a good thing.
Same in Java and Kotlin, but then again, the majority of people who write code wouldn't understand what I mean when I say "whether a collection is returned as List or Set is an important part of the API 'contract'".
One of the craziest bugs I have had in C++ was due to auto, and it would only trigger when Trump would announce tariffs. It would have been completely preventable if I had paid full attention to my IDE feedback or the correct compiler flags were set.
Things like this are why I don't get when anyone calls Rust "more difficult than C++". I don't think I've ever encountered a more complex and cumbersome language than C++.
Rust types can be very verbose, RefCell<Optional<Rc<Vec<Node>>>>
And lifetime specifiers can be jarring. You have to think about how the function will be used at the declaration site. For example usually a function which takes two string views require different lifetimes, but maybe at call site you would only need one. It is just more verbose.
C++ has a host of complexities that come with header/source splits, janky stdlib improvements like lock_guard vs scoped_lock, quirky old syntax like virtual = 0, a lack of build systems and package managers.
> Rust types can be very verbose, RefCell<Optional<Rc<Vec<Node>>>>
Anything in any language can be very verbose and confusing if you one-line it or obfuscate it or otherwise write it in a deliberately confusing manner. That's not a meaningful point imo. What you have to do is compare what idiomatic code looks like between the two languages.
C++ has dozens of pages of dense standardese to specify how to initialise an object, full with such text as
> Only (possibly cv-qualified) non-POD class types (or arrays thereof) with automatic storage duration were considered to be default-initialized when no initializer is used. Each direct non-variant non-static data member M of T has a default member initializer or, if M is of class type X (or array thereof), X is const-default-constructible,
if T is a union with at least one non-static data member, exactly one variant member has a default member initializer,
if T is not a union, for each anonymous union member with at least one non-static data member (if any), exactly one non-static data member has a default member initializer, and each potentially constructed base class of T is const-default-constructible.
For me, it's all about inherent complexity vs incidental complexity. The having to pay attention to lifetimes is just Rust making explicit the inherent complexity of managing values and pointers thereof while making sure there isn't concurrent mutation, values moving while pointers to them exist, and no data races. This is just tough in itself. The aforementioned C++ example is just the language being byzantine and giving you 10,000 footguns when you just want to initialise a class.
> > Only (possibly cv-qualified) non-POD class types (or arrays thereof) with automatic storage duration were considered to be default-initialized when no initializer is used. Each direct non-variant non-static data member M of T has a default member initializer or, if M is of class type X (or array thereof), X is const-default-constructible, if T is a union with at least one non-static data member, exactly one variant member has a default member initializer, if T is not a union, for each anonymous union member with at least one non-static data member (if any), exactly one non-static data member has a default member initializer, and each potentially constructed base class of T is const-default-constructible.
That's just a list of very simple rules for each kind of type. As a C++-phob person, C++ has a lot of footguns, but this isn't one of them.
Type deduction is a form of type inference, a very restricted/crude form of type inference that only considers the type of the immediate expression. The term is used in C++ because it predates the use of auto and was the term used to determine how to implicitly instantiate templates. auto uses exactly the same rules (with 1 single exception) as template type deduction, so the name was kept for familiarity. If instead of initializing a variable, you went through the examples on this website and passed the expression into a template function, the type would be deduced in exactly the same way with the exception of initializer lists.
Type inference is usually reserved for more general algorithms that can inspect not only how a variable is initialized, but how the variable used, such as what functions it's passed into, etc...
> Type inference is usually reserved for more general algorithms that can inspect not only how a variable is initialized, but how the variable used, such as what functions it's passed into, etc...
In a modern context, both would be called "type inference" because unidirectional type inference is quite a bit more common now than the bidirectional kind, given that many major languages adopted it.
If you want to specify constraint-based type inference then you can say global HM (e.g. Haskell), local HM (e.g. Rust), or just bidirectional type inference.
Type inference is when you try to infer a type from its usage. ``auto`` does no such thing, it just copies a known type from source to target. Target has no influence over source's type.
Inference is a constraint solving problem: the type of a variable depends on all the ways it is used. In C++, deduction simply sets the type of a variable from its initializing expression.
95%[1] of the time, deduction is enough, but occasionally you really wish you had proper inference.
The same general concepts often have different terminology between different languages. For example, which is better, a parent class or a super class? Or a method function or a member function? Initializer or constructor? Long list of these synonyms.
Saving this to use as an argument when C++ comes up in a discussion. This toxic swamp cannot be fixed and anyone chosing to jump into it needs a warning.
Most of the relevance of this is limited to C++ library authors doing metaprogramming.
Most of the "ugly" of these examples only really matters for library authors and even then most of the time you'd be hard pressed to put yourself in these situations. Otherwise it "just works".
Basically any adherence to a modicum of best practices avoids the bulk of the warts that come with type deduction or at worst reduces them to a compile error.
I see this argument often. It is valid right until you get first multipage error message from a code that uses stl (which is all c++ code, because it is impossible to use c++ without standard library).
Those aren't the ugly part of C++ and to be entirely honest reading those messages is not actually hard, it's just a lot of information.
Those errors are essentially the compiler telling you in order:
1. I tried to do this thing and I could not make it work.
2. Here's everything I tried in order and how each attempt failed.
If you read error messages from the top they make way more sense and if reading just the top line error doesn't tell you what's wrong, then reading through the list of resolution/type substitution failures will be insightful. In most cases the first few things it attempted will give you a pretty good idea of what the compiler was trying to do and why it failed.
If the resolution failures are a particularly long list, just ctrl-f/grep to the thing you expected to resolve/type-substitute and the compiler will tell you exactly why the thing you wanted it to use didn't work.
They aren't perfect error messages and the debugging experience of C++ metaprogramming leaves a lot to be desired but it is an order of magnitude better than it ever has been in the past and I'd still take C++ wall-o-error over the extremely over-reductive and limited errors that a lot of compilers in other languages emit (looking at you Java).
But "I tried to do this thing" error is completely useless in helping to find the reason why the compiler didn't do the thing it was expected to do, but instead chose to ignore.
Say, you hit ambiguous overload resolution, and have no idea what actually caused it. Or, conversely, implicit conversion gets hidden, and it helpfully prints all 999 operator << overloads. Or there is a bug in consteval bool type predicate, requires clause fails, and compiler helpfully dumps list of functions that have differet arguments.
How do you debug consteval, if you cannot put printf in it?
Not everyone can use clang or even latest gcc in their project, or work in a familiar codebase.
And I see this argument often. People make too much fuss about the massive error messages. Just ignore everything but the first 10 lines and 99.9% of the time, the issue is obvious. People really exaggerate the amout of time and effort you spend dealing with these error messages. They look dramatic so they're very memeable, but it's really not a big deal. The percentage of hours I've spent deciphering difficult cpp error messages in my career is a rounding error.
Do you also consider that knowing type deduction is not necessary to fix those errors, unless you are writing a library? Because that is not my experience (c++ "career" can involve such wildly different codebases, it's hard to imagine what others must be dealing with)
There's actually multiple standard libraries for embedded applications and a lot of the standard library from C++11 and on was designed with embedded in mind in particular.
And with each std release the particularly nasty parts of std get decoupled from the rest of the library. So it's at the point nowadays where you can use all the commonly used parts of std in an embedded environment. So that means you get all your containers, iterators, ranges, views, smart/RAII pointers, smart/RAII concurrency primitives. And on the bleeding edge you can even get coroutines, generators, green threads, etc in an embedded environment with "pay for what you use" overhead. Intel has been pushing embedded stdlib really hard over the past few years and both they and Nvidia have been spearheading the senders and receivers concurrency effort. Intel uses S&R internally for handling concurrency in their embedded environments internal to the CPU and elsewhere in their hardware.
(Also fun side note but STL doesn't "really" stand for "standard template library". Some projects have retroactively decided to refer to it as that but that's not where the term STL comes from. STL stands for the Adobe "Software Technology Lab" where Stepanov's STL project was formed and the project prior to being proposed to committee was named after the lab.)
AFAIK Stepanov only joined Adobe much later. I think he was at HP during the development of the STL, but moved to SGI shortly after (possibly during standardization).
The other apocryphal derivation of STL I have heard is "STepanov and Lee".
freestanding requires almost all std library. Please note that -fno-rtti and -fno-exceptions are non-conformant, c++ standard does not permit either.
Also, such std:: members as initializer_list, type_info etc are directly baked into compiler and stuff in header must exactly match internals — making std library a part of compiler implementation
have you actually read the page you linked to? None of the standard containers is there, nor <iostream> or <algorithm>. <string> is there but marked as partial.
If anything, I would expect more headers like <algorithm>, <span>, <array> etc to be there as they mostly do not require any heap allocation nor exceptions for most of their functionality. And in fact they are available with GCC.
The only bit I'm surprised is that coroutine is there, as they normally allocate, but I guess it has full support for custom allocators, so it can be made to work on freestanding.
> Please note that -fno-rtti and -fno-exceptions are non-conformant, c++ standard does not permit either.
I did not know that.
My understanding was that C does not require standard library functions to be present in freestanding. The Linux kernel famously does not build in freestanding mode, since then GCC can't reason about the standard library functions which they want. This means that they need to implement stuff like memcpy and pass -fno-builtin.
Does that mean that freestanding C++ requires the C++ standard library, but not the C standard library? How does that work?
Honestly? No idea how the committee is thinking. When, say, gamedev people write proposal, ask for a feature, explain it is important and something they depend on and so on, it gets shot down on technicality. Then they turn around and produce some insane feature that, like, rips everything east to west (like modules), and suddenly voting goes positive.
The "abstract machine" C++ assumes in the standard is itself a deeply puzzling construct. Luckily, compiler authors seem much more pragmatic and reasonable, I do not fear -fno-exceptions dissapearing suddenly, or code that accesses mmapped data becoming invalid because it didn't use start_lifetime_as
Usually codebases disallow auto because without an IDE it's difficult to see the type. I think this reduces the cognitive load of C++ a bit. The only time it is allowed is getting iterators types from STL containers.
I remember fretting about these rules when reading Scott Meyer's Effective C++11, and then later to realize it's better not to use auto at all. Explicit types are good types
Hard disagree. There are times when nobody, really nobody, cares about a given type. See the example of std::chrono::steady_clock::now over at cppreference.com. There you have
Looking up the (current standard's) return type of std::chrono::steady_clock::now() and spelling it out would serve no purpose here.With 'auto' it is so very verbose. It can be shorter. Let us put "using TP = std::chrono::steady_clock::time_point;" in some header file to be used in many places. Now you can write
I prefer to put the `using` in the block where you need the std::chrono code, which keeps it local and tidy. Putting it in a header is declaring a global type and asking for trouble; at least bound it in a namespace or a class.
how is TP more descriptive than auto here?
Some organizations don't like putting using declarations in headers since now you've got a global uniqueness requirement for the name "TP."
I agree, this would be in the same vein as "STL returns a verbose type, it's okay to use auto here because no-one cares"
> Usually codebases disallow auto because without an IDE it's difficult to see the type. I think this reduces the cognitive load of C++ a bit. The only time it is allowed is getting iterators types from STL containers.
Strong agree here. It's not just because it reduces cognitive load, it's because explicit types allows and requires the compiler to check your work.
Even if this isn't a problem when the code is first written, it's a nice safety belt for when someone does a refactor 6-12 months (or even 5+ years) down the road that changes a type. With auto, in the best case you might end up with 100+ lines of unintelligible error messages. In the worst case the compiler just trudges on and you have some subtle semantic breakage that takes weeks or months to chase down.
The only exceptions I like are iterators (whose types are a pita in C++), and lambda types, where you sometimes don't have any other good options because you can't afford the dynamic dispatch of std::function.
I know Google’s styleguide discourages auto, but other C++ places I’ve worked weren’t scared of it. The type deduction rules usually do what I expect, unless I have a weird pre-C++11 proxy type that somehow hasn’t been updated in the last 14 years.
I agree that auto should be used as little as possible. There are good uses, though. It is okay to use when the type is trivially inferred from the code. What is auto in "auto ptr = std::make_shared<MyNiceType>();". Everybody who knows any C++ knows. Also, lambdas do not have a type that can be written down, so it is okay to use auto for them.
I also prefer not to use auto when getting iterators from STL containers. Often I use a typedef for most STL containers that I use. The one can write MyNiceContainerType::iterator.
Pre LLM agents, a trick that I used was to type in
auto var = FunctionCall(...);
Then, in the IDE, hover over auto to show what the actual type is, and then replace auto with that type. Useful when the type is complicated, or is in some nested namespace.
That's what I still do. Replacing auto with deduced type is one of my favorite clangd code actions.
This makes things seem more complicated than they already are, I feel?
There's nothing special about auto here. It deduces the same type as a template parameter, with the same collapsing rules.
decltype(auto) is a different beast and it's much more confusing. It means, more or less, "preserve the type of the expression, unless given a simple identifier, in which case use the type of the identifier."
I always try to avoid auto in c++ or var in C#. On the paper it is a nice was to save you from typing out the type but this is only true if you have tool support and can use your mouse to obtain the type. In printouts or even in a text snippet I’m am lost. I think auto inC++ was the try to shorten some overburden type constructs and make it a little more friendly to use heavy templating. Please forgive my bad English. I’m no native speaker
The guidelines I follow for C# has "use var where it's obvious, but explicitly type when not".
So for example I'd write:
Because writing: Feels very redundantWhereas I'd write:
Because it's not obvious what the type is otherwise ( Some IDEs will overlay hint the type there though ).Although with newer language features you can also write:
Which is even better.I would rename `x` to `foos` and jump to the function/use IDE hints for the exact type when needed.
Right, although I would argue the most interesting part of the type here is the container, not the containee.
With good naming it should be pretty obvious it's a Foo, and then either you know the type by heart, or will need to look up the definition anyway.
With standard containers, you can have the assumption that everyone knows the type, at least high level. So knowing whether it's a list, a vector, a stack, a map or a multimap, ... is pretty useful and avoid a lookup.
an interesting demarcation of subjective mental encapsulation ... associating the anonymous type of a buffer with the buffer's name ... as opposed to explicitly specifying the type of an anonymously named buffer
I usually prefer
since it gives me better alignment and since it's not confused with dynamic.Nowadays I only use
in non-merged code as a ghetto TODO if I'm considering base types/interface.I came to like auto over the years, although I also use it sparingly. Sometimes the concrete types only add visual noise and not much helpful information, e.g. iterators:
auto it = some_container.begin();
Not even once have I wished to know the actual type of the iterator.
It’s extremely convenient for certain things. For example, let’s say I’m referring to an enum constant field of a deeply-nested type. This can easily be expressed as “auto k = a.b.c.d.kind” instead of “Alpha::Bet::Charlie::Delta::Kinds k = a.b.c.d.kind”. It should be used sparingly in local contexts where the meaning cannot be confusing.
That is like saying that one rather make fire with sticks and stones than with a lighter, because otherwise one would be lost when going out camping.
IDEs are an invention from the late 1970's, early 1980's.
I think IDEs are a moving target. Do you consider syntax highlighting to make something an IDE? Macro expansion? Autocomplete? intellisense-like based on full text search? based on a parser? based on the compiler? Is Kate an editor or an IDE? It has LSP support.
Having syntax highlighting makes me slightly faster, but I want to still be able to understand things, when looking at a diff or working over SSH and using cat.
Nope, that is a programmer's editor.
Very much true. On the other hand web based review interfaces seem to be stuck in the '60, when they could be so much better if they properly integrated with the compiler.
The ones on Github with VSCode (Web) integration look quite good already.
auto has a good perk, it prevents uninitialized values (Which is a source of bugs).
For example:
auto a;
will always fail to compile not matter what flags.
int a;
is valid.
Also it prevents implicit type conversions, what you get as type on auto is the type you put at the right.
That's good.
uninitialized values are not the source of bugs. This is a good way to find logic errors in code (e.g. using sanitizer)
This is indeed exactly correct. Probably on its own this is the most important reason for most people to use it, as I think most of the millions of C++ developers in the world (and yes there are apparently millions) are not messing with compiler flags to get the checks that probably should be there by default anyway. The keyword auto gives you that.
Maybe an in-between solution could be a tool that substitutes auto in your code.
Odd, it's not a problem in dynamically typed languages or languages like Kotlin, Swift, etc. I think it's more just what you're used to.
I knew the answer to most of these intuitively but the story isn’t great. Regardless of the programming language, I’ve always been an “auto” minimalist. There are relatively few contexts where relying on inference is justified by the expedience. Ignoring the issues raises by the article, explicitness simplifies things and reduces bugs.
That said, there are some contexts in which “auto” definitely improves the situation.
You will typically find bugs go up when you do not use auto in most average C++ code bases because, as noted by another comment, a lot of C++ developers have the bad habit of writing uninitialized variables, which auto prevents.
As a C developer to me uninitialized variables are a feature and I love to invoke UB with __builtin_unreachable, because it makes the compiler able to actually bark at me on incorrect usage instead of it silently working.
Automatic conversion between numeric types is also a fun source of bugs.
The last time I worked meaningfully with C++ was back in 2013. Now that I write mostly Rust and TypeScript, I'm amazed by how C++ has changed over the years!
Regarding the "auto" in C++, and technically in any language, it seems conceptually wrong. The ONLY use-case I can imagine is when the type name is long, and you don't want to type it manually, or the abstractions went beyond your control, which again I don't think is a scalable approach.
Type inference is actually very useful you just need to have the right amount, too little and most of your time is spent on bureaucracy, too much and the software is incomprehensible.
In both Rust and C++ we need this because we have unnameable types, so if their type can't be inferred (in C++ deduced) we can't use these types at all.
In both languages all the lambdas are unnameable and in Rust all the functions are too (C++ doesn't have a type for functions themselves only for function pointers and we can name a function pointer type in either language)
Another place where auto can be useful is to handle cases where the function signature changes without making changes at the calling site. An explicitly typed var would need changing or worse, can work with some potential hidden bugs due to implicit type conversion.
> C++ doesn't have a type for functions themselves only for function pointers
C has this, so I think C++ has as well. You can use a typedef'ed function to declare a function, not just for the function pointer.
Same in C++. You can't do much with the function type itself as there are no objects with that type, but you can create references and pointers to it.
But
works?Those are function pointers. Your parent was referring to the function type. Per ISO/IEC 9899:TC3:
A function type describes a function with specified return type. A function type is characterized by its return type and the number and types of its parameters. A function type is said to be derived from its return type, and if its return type is T , the function type is sometimes called ‘‘function returning T’’. The construction of a function type from a return type is called ‘‘function type derivation’’.
Not necessarily, foo can also just be an ordinary function. That was my point.
> Per ISO/IEC 9899:TC3:
What is it supposed to tell me?
This is true, in both C++ and C, you can use a function type to declare (but not define) a function! This pretty much never comes up and I forgot.
edit: you literally said this in your original comment. I failed at reading comprehension.
> This pretty much never comes up
I regularly use that in C, to make sure a function matches an abstract interface. Sure, that often ends up in a function pointer, but not always and when I declare the type signature, it isn't yet a function pointer.
> but not define
I think that is because the type signature only contains the types, but no parameter names, which are required for a definition. This is arbitrary, since for data types, the member names are part of the type. It sounds totally fixable, but then you either have two types of function types, one where all parameter names are qualified and one where they aren't and only could use the former for function definitions. Or you would make names also mandatory for function declarations.
Interesting use case.
> It sounds totally fixable, but then you either have two types of function types, one where all parameter names are qualified and one where they aren't and only could use the former for function definitions
Making the names part of the type would be a bit weird, although we have seen stranger things. The biggest problem is that it would be a breaking change at least in C++.
Auto is fine where the context is obvious, I think. For e.g.:
Here it's obvious that v is of type double.v is double& in your example, not double. But it's not obvious that omitting the & causes a copy. If you see "for (auto v : vec)" looks good right? But if vec contains eg long strings, you've now murdered your perf because you're copying them out of the array instead of grabbing refs. Yes, you could make the same mistake without auto, but it's easier to notice. It's easy to forget (or not notice) that auto will not resolve to a reference in this case, because using a reference is "obviously what I want here", and the name of the feature is "auto" after all - "surely it will figure it out, right?"
> But if vec contains eg long strings, you've now murdered your perf because you're copying them out of the array instead of grabbing refs.
I've seen much more perf-murdering things being caused by
than with auto thoughWow I really thought this would be a compile error. The implicit cast here really is a footgun. Looks like '-Wrange-loop-construct' (included in -Wall) does catch it:
> warning: loop variable 'v' of type 'const std::pair<std::__cxx11::basic_string<char>, int>&' binds to a temporary constructed from type 'std::pair<const std::__cxx11::basic_string<char>, int>' [-Wrange-loop-construct] 11 | for (const std::pair<std::string, int>& v: m) {
As they say, the power of names...
Why is this a perf footgun? As someone who doesn't write a lot of c++, I don't see anything intuitively wrong.
Is it that iterating over map yields something other than `std::pair`, but which can be converted to `std::pair` (with nontrivial cost) and that result is bound by reference?
Close, it is a std::pair, but it differs in constness. Iterating a std::map<K, V> yields std::pair<const K, V>, so you have:
vsAnd what does casting const change, that would involve runtime inefficiencies?
It is not a cast. std::pair<const std::string, ...> and std::pair<std::string,...> are different types, although there is an implicit conversion. So a temporary is implicitly created and bound to the const reference. So not only there is a copy, you have a reference to an object that is destroyed at end of scope when you might expect it to live further.
Each entry in the map will be copied. In C++, const T& is allowed to bind to a temporary object (whose lifetime will be extended). So a new pair is implicitly constructed, and the reference binds to this object.
> Yes, you could make the same mistake without auto, but it's easier to notice.
Is it really? I rather think that a missing & is easier to spot with "auto" simply because there is less text to parse for the eye.
> If you see "for (auto v : vec)" looks good right?
For me the missing & sticks out like a sore thumb.
> It's easy to forget (or not notice) that auto will not resolve to a reference in this case
Every feature can be misused if the user forgets how it works. I don't think people suddenly forget how "auto" works, given how ubiquitous it is.
It's a foot gun. Why is the default target for this gun my foot? "You should be careful to choose the target properly" isn't an answer to that question.
In what way it is a footgun? auto x = ... ; does what I would expect. Copying is usually the default in C++ and that's what I would expect to happen here.
If auto deduced reference types transparently, it would actually be more dangerous.
Copying is a weird default because who said that's even achievable, let alone cheap?
So I guess I depart from you there and thus my issue here is not really about auto
C++ has value semantics, which means that values of user-defined types generally behave like values of built-in types. In this sense, copying is the only logical default. It's just how the language has been designed.
Things are different in Rust because of lifetimes and destructive moves. In this context, copying would be a bad default indeed.
> because who said that's even achievable, let alone cheap?
Nobody said that. The thing is that user-defined types can be anything from tiny and cheap to huge and expensive. A language has to pick one default and be consistent. You can complain one way or the other.
That's exactly what I was about to write!
Auto has really made c++ unapproachable to me. It's hard enough to reason about anything templated, and now I frequently see code where every method returns auto. How is any one supposed to do a code review without loading the patch into their IDE?
I'd suppose this really depends on how you are developing your codebase but most code should probably be using a trailing return type or using an auto (or template) return type with a concept/requires constraint on the return type.
For any seriously templated or metaprogrammed code nowadays a concept/requires is going to make it a lot more obvious what your code is actually doing and give you actually useful errors in the event someone is misusing your code.
I don't understand why anyone would use auto and a trailing return type for their functions. The syntax is annoying and breaks too much precedent.
1) consistency, 2) scoping is different and can make it a significant difference.
I have been programming in C++ for 25 years, so I'm so used to the original syntax that I don't default to auto ... ->, but I will definitely use it when it helps simplify some complex signatures.
Generally, you don't. I'm not sure why the parent suggested you should normally do this. However, there are occasional specific situations in which it's helpful, and that's when you use it.
It just is an improvement for a bunch of reasons.
1. Consistency across the board (places where it's required for metaprogramming, lambdas, etc). And as a nicety it forces function/method names to be aligned instead of having variable character counts for the return type before the names. IMHO it makes skimming code easier.
2. It's required for certain metaprogramming situations and it makes other situations an order of magnitude nicer. Nowadays you can just say `auto foo()` but if you can constrain the type either in that trailing return or in a requires clause, it makes reading code a lot easier.
3. The big one for everyday users is that trailing return type includes a lot of extra name resolution in the scope. So for example if the function is a member function/method, the class scope is automatically included so that you can just write `auto Foo::Bar() -> Baz {}` instead of `Foo::Baz Foo::Bar() {}`.
1. You're simply not going to achieve consistency across the board, because even if you dictate this by fiat, your dependencies won't be like this. The issue of the function name being hard to spot is easier to fix with tooling (just tell your editor to color them or make them bold or something). OTOH, it's not so nice to be unable to tell at a glance if the function return type is deduced or not, or what it even is in the first place.
2. It's incredibly rare for it to be required. It's not like 10% of the time, it's more like < 0.1% of the time. Just look at how many functions are in your code and how many of them actually can't be written without a trailing return type. You don't change habits to fit the tiny minority of your code.
3. This is probably the best reason to use it and the most subjective, but still not a particularly compelling argument for doing this everywhere, given how much it diverges from existing practice. And the downside is the scope also includes function parameters, which means people will refer to parameters in the return type much more than warranted, which is decidedly not always a good thing.
it makes function declarations/instantiations much more grep-able.
Consistency (lambdas, etc.)
The pain of lisp without any of the joy.
Same in Java and Kotlin, but then again, the majority of people who write code wouldn't understand what I mean when I say "whether a collection is returned as List or Set is an important part of the API 'contract'".
One of the craziest bugs I have had in C++ was due to auto, and it would only trigger when Trump would announce tariffs. It would have been completely preventable if I had paid full attention to my IDE feedback or the correct compiler flags were set.
This has got to be a hell of a story if it's true.
Things like this are why I don't get when anyone calls Rust "more difficult than C++". I don't think I've ever encountered a more complex and cumbersome language than C++.
Rust types can be very verbose, RefCell<Optional<Rc<Vec<Node>>>>
And lifetime specifiers can be jarring. You have to think about how the function will be used at the declaration site. For example usually a function which takes two string views require different lifetimes, but maybe at call site you would only need one. It is just more verbose.
C++ has a host of complexities that come with header/source splits, janky stdlib improvements like lock_guard vs scoped_lock, quirky old syntax like virtual = 0, a lack of build systems and package managers.
> Rust types can be very verbose, RefCell<Optional<Rc<Vec<Node>>>>
Anything in any language can be very verbose and confusing if you one-line it or obfuscate it or otherwise write it in a deliberately confusing manner. That's not a meaningful point imo. What you have to do is compare what idiomatic code looks like between the two languages.
C++ has dozens of pages of dense standardese to specify how to initialise an object, full with such text as
> Only (possibly cv-qualified) non-POD class types (or arrays thereof) with automatic storage duration were considered to be default-initialized when no initializer is used. Each direct non-variant non-static data member M of T has a default member initializer or, if M is of class type X (or array thereof), X is const-default-constructible, if T is a union with at least one non-static data member, exactly one variant member has a default member initializer, if T is not a union, for each anonymous union member with at least one non-static data member (if any), exactly one non-static data member has a default member initializer, and each potentially constructed base class of T is const-default-constructible.
For me, it's all about inherent complexity vs incidental complexity. The having to pay attention to lifetimes is just Rust making explicit the inherent complexity of managing values and pointers thereof while making sure there isn't concurrent mutation, values moving while pointers to them exist, and no data races. This is just tough in itself. The aforementioned C++ example is just the language being byzantine and giving you 10,000 footguns when you just want to initialise a class.
> > Only (possibly cv-qualified) non-POD class types (or arrays thereof) with automatic storage duration were considered to be default-initialized when no initializer is used. Each direct non-variant non-static data member M of T has a default member initializer or, if M is of class type X (or array thereof), X is const-default-constructible, if T is a union with at least one non-static data member, exactly one variant member has a default member initializer, if T is not a union, for each anonymous union member with at least one non-static data member (if any), exactly one non-static data member has a default member initializer, and each potentially constructed base class of T is const-default-constructible.
That's just a list of very simple rules for each kind of type. As a C++-phob person, C++ has a lot of footguns, but this isn't one of them.
“How well do you know Latin grammar rules?”
Romanes eunt domus
Apparently the C++ standard calls this type deduction. But I've always called it type inference.
Type deduction is a form of type inference, a very restricted/crude form of type inference that only considers the type of the immediate expression. The term is used in C++ because it predates the use of auto and was the term used to determine how to implicitly instantiate templates. auto uses exactly the same rules (with 1 single exception) as template type deduction, so the name was kept for familiarity. If instead of initializing a variable, you went through the examples on this website and passed the expression into a template function, the type would be deduced in exactly the same way with the exception of initializer lists.
Type inference is usually reserved for more general algorithms that can inspect not only how a variable is initialized, but how the variable used, such as what functions it's passed into, etc...
> Type inference is usually reserved for more general algorithms that can inspect not only how a variable is initialized, but how the variable used, such as what functions it's passed into, etc...
In a modern context, both would be called "type inference" because unidirectional type inference is quite a bit more common now than the bidirectional kind, given that many major languages adopted it.
If you want to specify constraint-based type inference then you can say global HM (e.g. Haskell), local HM (e.g. Rust), or just bidirectional type inference.
Type inference is when you try to infer a type from its usage. ``auto`` does no such thing, it just copies a known type from source to target. Target has no influence over source's type.
https://news.ycombinator.com/item?id=11604474
Inference is a constraint solving problem: the type of a variable depends on all the ways it is used. In C++, deduction simply sets the type of a variable from its initializing expression.
95%[1] of the time, deduction is enough, but occasionally you really wish you had proper inference.
[1] percentage made up on the spot.
The same general concepts often have different terminology between different languages. For example, which is better, a parent class or a super class? Or a method function or a member function? Initializer or constructor? Long list of these synonyms.
Saving this to use as an argument when C++ comes up in a discussion. This toxic swamp cannot be fixed and anyone chosing to jump into it needs a warning.
Most of the relevance of this is limited to C++ library authors doing metaprogramming.
Most of the "ugly" of these examples only really matters for library authors and even then most of the time you'd be hard pressed to put yourself in these situations. Otherwise it "just works".
Basically any adherence to a modicum of best practices avoids the bulk of the warts that come with type deduction or at worst reduces them to a compile error.
I see this argument often. It is valid right until you get first multipage error message from a code that uses stl (which is all c++ code, because it is impossible to use c++ without standard library).
Those aren't the ugly part of C++ and to be entirely honest reading those messages is not actually hard, it's just a lot of information.
Those errors are essentially the compiler telling you in order:
1. I tried to do this thing and I could not make it work.
2. Here's everything I tried in order and how each attempt failed.
If you read error messages from the top they make way more sense and if reading just the top line error doesn't tell you what's wrong, then reading through the list of resolution/type substitution failures will be insightful. In most cases the first few things it attempted will give you a pretty good idea of what the compiler was trying to do and why it failed.
If the resolution failures are a particularly long list, just ctrl-f/grep to the thing you expected to resolve/type-substitute and the compiler will tell you exactly why the thing you wanted it to use didn't work.
They aren't perfect error messages and the debugging experience of C++ metaprogramming leaves a lot to be desired but it is an order of magnitude better than it ever has been in the past and I'd still take C++ wall-o-error over the extremely over-reductive and limited errors that a lot of compilers in other languages emit (looking at you Java).
Most of the time it's as uou say!
But "I tried to do this thing" error is completely useless in helping to find the reason why the compiler didn't do the thing it was expected to do, but instead chose to ignore.
Say, you hit ambiguous overload resolution, and have no idea what actually caused it. Or, conversely, implicit conversion gets hidden, and it helpfully prints all 999 operator << overloads. Or there is a bug in consteval bool type predicate, requires clause fails, and compiler helpfully dumps list of functions that have differet arguments.
How do you debug consteval, if you cannot put printf in it?
Not everyone can use clang or even latest gcc in their project, or work in a familiar codebase.
To be fair to C++, the only languages with actually decently debuggable metaprograms are Lisp and Prolog.
Modern C++ in general is so hostile to debugging I think it's astounding people actually use it.
And I see this argument often. People make too much fuss about the massive error messages. Just ignore everything but the first 10 lines and 99.9% of the time, the issue is obvious. People really exaggerate the amout of time and effort you spend dealing with these error messages. They look dramatic so they're very memeable, but it's really not a big deal. The percentage of hours I've spent deciphering difficult cpp error messages in my career is a rounding error.
Do you also consider that knowing type deduction is not necessary to fix those errors, unless you are writing a library? Because that is not my experience (c++ "career" can involve such wildly different codebases, it's hard to imagine what others must be dealing with)
> it is impossible to use c++ without standard library
Citation needed. This is common for embedded application, since why would anyone program a STL for that?
There's actually multiple standard libraries for embedded applications and a lot of the standard library from C++11 and on was designed with embedded in mind in particular.
And with each std release the particularly nasty parts of std get decoupled from the rest of the library. So it's at the point nowadays where you can use all the commonly used parts of std in an embedded environment. So that means you get all your containers, iterators, ranges, views, smart/RAII pointers, smart/RAII concurrency primitives. And on the bleeding edge you can even get coroutines, generators, green threads, etc in an embedded environment with "pay for what you use" overhead. Intel has been pushing embedded stdlib really hard over the past few years and both they and Nvidia have been spearheading the senders and receivers concurrency effort. Intel uses S&R internally for handling concurrency in their embedded environments internal to the CPU and elsewhere in their hardware.
(Also fun side note but STL doesn't "really" stand for "standard template library". Some projects have retroactively decided to refer to it as that but that's not where the term STL comes from. STL stands for the Adobe "Software Technology Lab" where Stepanov's STL project was formed and the project prior to being proposed to committee was named after the lab.)
AFAIK Stepanov only joined Adobe much later. I think he was at HP during the development of the STL, but moved to SGI shortly after (possibly during standardization).
The other apocryphal derivation of STL I have heard is "STepanov and Lee".
gladly! Since deep-linking draft pdf from phone is hard, here is the next best thing: https://en.cppreference.com/w/cpp/freestanding.html
freestanding requires almost all std library. Please note that -fno-rtti and -fno-exceptions are non-conformant, c++ standard does not permit either.
Also, such std:: members as initializer_list, type_info etc are directly baked into compiler and stuff in header must exactly match internals — making std library a part of compiler implementation
> freestanding requires almost all std library.
have you actually read the page you linked to? None of the standard containers is there, nor <iostream> or <algorithm>. <string> is there but marked as partial.
If anything, I would expect more headers like <algorithm>, <span>, <array> etc to be there as they mostly do not require any heap allocation nor exceptions for most of their functionality. And in fact they are available with GCC.
The only bit I'm surprised is that coroutine is there, as they normally allocate, but I guess it has full support for custom allocators, so it can be made to work on freestanding.
> Please note that -fno-rtti and -fno-exceptions are non-conformant, c++ standard does not permit either.
I did not know that.
My understanding was that C does not require standard library functions to be present in freestanding. The Linux kernel famously does not build in freestanding mode, since then GCC can't reason about the standard library functions which they want. This means that they need to implement stuff like memcpy and pass -fno-builtin.
Does that mean that freestanding C++ requires the C++ standard library, but not the C standard library? How does that work?
Honestly? No idea how the committee is thinking. When, say, gamedev people write proposal, ask for a feature, explain it is important and something they depend on and so on, it gets shot down on technicality. Then they turn around and produce some insane feature that, like, rips everything east to west (like modules), and suddenly voting goes positive.
The "abstract machine" C++ assumes in the standard is itself a deeply puzzling construct. Luckily, compiler authors seem much more pragmatic and reasonable, I do not fear -fno-exceptions dissapearing suddenly, or code that accesses mmapped data becoming invalid because it didn't use start_lifetime_as
So as to your understanding
> freestanding C++ requires the C++ standard library, but not the C standard library
is true?
> The "abstract machine" C++ assumes in the standard is itself a deeply puzzling construct.
I find the abstract machine to be quite a neat abstraction, but I am also more of a C guy.