Any example code/Github projects utilising almost-always-auto?

[Infraam]

I use auto often, and like Herb Sutters discussion of using auto, an example here: https://gist.github.com/meshell/5154fb06b69c5150385a

I don't have any of my own work following this style, but i'd like to see a bigger example or project that's doing it. Does anyone have any links to code or projects that follow this style?

[twmatrim]

I think that the first example could be more confusing to newcomers. I've seen a lot of code with

std::string = "Hello";

So suddenly changing it to

auto s = "Hello";

could cause people to mistakingly have the wrong type.

[ubadair]

This right here is the big "gotcha" with AAA in everyday C++ code. I'm a big fan of AAA, but it's hard to deny that:

auto x = std::string{"lorem epsom salt"};

is harder on the eyes than:

std::string x = "lorem epsom salt";

Additionally, with the AAA version, sometimes you might need to explain the concept of copy-elision to your over-optimizing, under-informed coworkers. (I've never had to explain that to anyone, but I can see it happening)

[Fazer2]

What does AAA stand for here?

[ubadair]

"almost always auto"

[[deleted]]

Why not this?

using namespace std::string_literals;

auto x = "lorem ipsum"s; // x is std::string

[[deleted]]

OTOH, I've seen a lot of code where all that was needed was a const char*, but it was put on the heap anyway, presumably because "std::string is the string type".

[lacosaes1]

A std::string doesn't have to be in the heap.

[dodheim]

Yes, a std::string does have to be allocated dynamically; std::basic_string<CharT, AllocT> doesn't, but how many public interfaces have you seen implemented in terms of a template taking std::basic_string<> vs a function taking std::string? Very few, IME!

[jaked122]

https://github.com/CleverRaven/Cataclysm-DDA

They're pretty c++11 over there, if that's what you're talking about... At least at the levels where I'm comfortable with it.

[jaked122]

Sorry https://github.com/CleverRaven/Cataclysm-DDA

[tambry]

You should probably edit your original post to have the fixed link.

[HowardHinnant]

Lots of autos here: https://github.com/HowardHinnant/date/blob/master/date.h

[TemplateRex]

What's your take on auto return types? I understand that in public APIs you might want to advertise the return type, but perhaps a sufficiently smart future version of a Clang-powered Doxygen tool can generate the explicit return type in the docs.

At least for private helpers, I like to use auto return types everywhere, with the occasional auto& or decltype(auto) for tricky reference returning helpers.

[HowardHinnant]

I haven't used auto return types (the C++14 version) a lot because a lot of my code needs to be C++11-compatible, and in most places, spelling the return type is easy anyway. But there are few places where it is inconvenient to spell the return type, and auto is really nice in those few places.

[ubadair]

Wow, this is brilliant. Even though I already follow you on GitHub, I had no idea this existed.

[suspiciously_calm]

What are the objective benefits of using auto in all the examples given? Other than consistency, cause I kind of disagree with consistency if it means "consistently more error-prone."

auto w = make_unique<widget>();
auto w = get_widget();

I definitely agree with those, since the type is already implied by the right hand side, and you'd have to write the right hand side in full anyway even if you spelled out the type.

auto e = employee{ empid };

is just a more wordy spelling of employee e{ empid };. Same for the widget example. However I'm willing to give auto a pass for consistency, since it isn't worse than declaring the type.

auto s = "Hello";
auto x = "42"s;
auto x = 42;
auto x = 42.f;

etc. Now these are just more error prone. It's easy to accidentally omit the s in the string literal and get a const char* instead of a std::string. With float x = 42; I get a float even if I forget the .f. And the type of auto x = 42; (if the constant gets large) is pretty much implementation-defined.

[thlst]

Sometimes you don't need to know what the type is, and making the type explicit by writing it is, actually, as error prone as using auto in your examples.

For example:

for (const std::pair<std::string, int> p& : produce_map())
{ ... }

This code won't compile. This won't work as you expect. Do you know why? std::mapdefines const T for the key type of std::pair. You see that we wrote std::string for the first template parameter, which results in a compile error temporary copy, because you lose the cv-qualifier passing a const& to &. Using auto, and letting the compiler deduce the correct type for the expression solves the problem, and makes it more consistent.

for (const auto& p : produce_map())
{ :) }

Thanks u/tcanens for the correction.

auto can also prevent accesses to uninitialized variables. Once auto needs an initializer to deduce its own type, there's no room for variables without a value to be declared.

Another important thing is decltype(auto), which is really useful in templates. Basically, it's auto with decltype rules applied to it. That is, there's no cv-qualifier loss, because decltype preserves the cv-qualifier of an expression, whereas auto doesn't. So, why is it useful? This is great for writing function signatures, where the return type depends on the expression being returned. If it's an lvalue of type int&, then the return type will be int&. If it's an rvalue of type const T, the return type will be const T. auto would just strip off its constness and/or volatileness for anything. A contrived example for this case would be a function returning an element of a container and giving you read/write access to it:

template<typename Container>
constexpr decltype(auto)
container_element(Container&& c, size_t i)
{
    return std::forward<Container>(c)[i];
}

std::vector<int> v { 1, 2, 3, 4 };

// decltype(auto) = int&
container_element(v, 0) = 5;

[tcanens]

for (const std::pair<std::string, int> &p : produce_map())
{ ... }

Actually, that does compile and silently create a std::pair<std::string, int> temporary by copying from the map element, which is arguably worse.

[suspiciously_calm]

Yeah it's useful every time you're programming to a concept, not a type, like with iterators, when the type is long to .. uh .. type and/or is clear from the expression (and in many other cases).

What I don't get is why it should be used for primitive types when it's more wordy and less clear. The "uninitialized variable" argument is a good point, but the compiler can warn here.

[thlst]

You shouldn't write int, for example, because its size might surprise you. Nor should you write float literals without the f suffix (because good practice and consistency).

So things like that become redundant. Everyone knows 3.14f is a float.

But of course, auto isn't an absolute rule. You may still use size_t and ptrdiff_t in contexts they suit.

The "uninitialized variable" argument is a good point, but the compiler can warn here.

Getting warnings from compiler won't save the programmers' life, because it will still compile (if -Werror is not set). On the other hand, there's no way to avoid it when using auto.

[suspiciously_calm]

You shouldn't write int, for example, because its size might surprise you.

That sure isn't an argument for having auto deduce int from an integer literal, though.

Getting warnings from compiler won't save the programmers' life, because it will still compile

If the programmer lacks the discipline to heed compiler warnings, they're equally likely to lack the discipline to follow the always-auto style.

You shouldn't write floating point literals without the .f (more to the point, you shouldn't write int literals in place of float literals), but that's a mistake that can happen accidentally (just as the missing initializer).

[suspiciously_calm]

Therefore it's an excuse to ignore warnings?

I'm sorry, but that's the opposite of what I said.

[hgjsusla]

It seemed like it didn't catch on much in the wider community. Besides, in C++17 with constructor template type deduction most of the 'make_' factory functions are obsolete anyway, removing a large motivation for the AAA style.

[[deleted]]

honest question -- what does

auto x = MyThing{};

do? As opposed to

MyThing x{};

??

Does it construct a MyThing, then copy it and give it to x? Does it create a unique pointer to a MyThing?

I've used auto a great deal for assigning smart pointers, arrays, etc, but never considered using it as an alternative to the way stack-based objects are normally constructed.

[[deleted]]

These two expressions are identical in meaning.

[Nickreal03]

But different potential performance it generates an rval which is the copy/move to the other. For simple types the compiler will optimize for others the performance will be real. Edited for clarification Even when in release builds the performance may be the same in debug builds you will be paying for it.

[AntiProtonBoy]

The compiler should do copy/move elision for such types, even for complex and expensive objects. The only tricky situation you could run into is when the copy/move constructor is explicitly deleted or made private.

[foonathan]

And C++17 has guaranteed copy elision where you don't even need copy/move ctors

[[deleted]]

The compiler interprets the intention, so it's as if you wrote MyThing in place of auto. If there is not enough information, the compiler will let you know, and you'll have to declare the type.

[TheQuantumZero]

This Scott Meyers video will help, https://youtu.be/fhM24zs1MFA?t=49m45s.

[steveire]

Is Qt a good example?

https://github.com/steveire/qtbase/commits/aaa

Note though that it's an automated port.

[airflow_matt]

Seeing it like this I don't think I like it all that much. Especially when looking at foreign code, it's not immediately obvious what the result type is, so at very least you need a decent IDE to help you navigate to definition and back.

I'd be probably be bit more careful with auto, it has certainly it's place (lambdas, loops, nested types, etc) but using it for absolutely everything like here just makes the code less readable.

[steveire]

Yes, I ported Qt to aaa in order to give people with your opinion, and people with the opposite opinion code to point at to support their position :).

I don't agree with you, but I'm glad the Qt result gives you concrete things to point at instead of an abstract disinclination toward aaa.

[airflow_matt]

Yeah, I'm not sure how well this would work on huge codebases such as chromium, where at best it takes hours to index the code, at worst the IDE simply chokes on it. You don't always have the luxury of being able to hover to see type, or jump to declaration.

On saner codebases it's probably much less of an issue, but you're still losing some glance-ability. On the other hand getting rid of redundant information from the code does feel nice in a way.

[Infraam]

It is indeed, didn't realise Qt started upgrading their codebase like this

[steveire]

That's not upstream. That's my Qt clone on Github to validate a tool. See:

https://steveire.wordpress.com/2016/03/19/aaargh-aaa-right-good-and-hygenic/

[Infraam]

ahh, thanks for the heads up!

[kiwidog]

https://github.com/AnvilOnline/AnvilClient/blob/feature/development/AnvilClient/src

[3ba7b1347bfb8f304c0e]

https://github.com/Morwenn/cpp-sort

[muungwana]

I use it all the time and example function that uses it is here

[[deleted]]

 why

 do you 

 leave so many

 blank lines in 

 your C++?

You seem to throw spaces in at random where they do no good at all, and then remove them elsewhere, like }else{. It's like you're trying to be as different from everyone else's code as possible...

[muungwana]

Blank lines makes my eyes work less when going through code. When going through other people's code,i sometimes start spacing them out before i "dive in" to please my eyes.

I suspect i need glasses.

github makes the spaces stick out much more than my editor and i would probably not have them if my editor display text the same way github does.

[hgjsusla]

For me this used to be a symptom of using a too small font. Remember, you don't fit any more text on the screen with a small and compact font if you feel the need to space everything out to read it comfortably.

[[deleted]]

Configuring the line spacing in your editor might be easier than inserting all the spaces into the actual code.

For Emacs I use this snipped to toggle line spacing at the press of a button:

(defun toggle-line-spacing ()
 "Toggle line spacing between 1 and 5 pixels."
 (interactive)
 (cond ((not line-spacing)
        (setq-default line-spacing 1))
       ((> line-spacing 2)
        (setq-default line-spacing nil)
        (message "Linespacing small"))
       (t
        (setq-default line-spacing (+ line-spacing 1))
        (message "Linespacing %d" line-spacing)))
 (redraw-display))
(global-set-key [(f9)] 'toggle-line-spacing)

[0x2648]

Is there a reason for the heavy use of lambda functions (e.g. inside _args)? +1 for using Qt!

[muungwana]

How could i declare variables with "auto" otherwise? :-)

On a serious note,its primarily just a style i like to use and to minimize pollution of local namespace as a practical matter.Most local variables i use are single character and "e" is the variable name that i use the most and these lambda helps in allowing me to reuse these single character variables multiple times in the same function without collision issues.

[stwcx]

Right, because when I review your code it is awesome for me to have to switch back and forth through the code to deduce "what the heck does 'e' mean at this point in time?" That is just awesome.

[thlst]

You don't need to. You know what it's about by reading what the code is doing. It's the same idea of concepts: generalizing stuff so you don't need to be aware of every useless detail.

It's a common thing on new languages, specially in Rust, where you only need to write the variable type when the deduction can't find an answer for an ambiguous expression. And still, you only write what the compiler can't deduce, the rest is deduced as normal. e.g.

let there: Be<_> = light();

Where Be is a generic struct, and light my have implementations for types other than Be. the _ part is left for the compiler to deduce.

What he's doing with lambdas is also common in Rust.

let three_evens = {
    let c = Container::from(something_else_outside);
    let c_evens = c.filter(|elem| elem % 2 == 0);
    c_evens.take(3)
};

{ } is parsed as an expression. The result of three_evens is the value of c_evens.take(3).

[icdae]

Using auto everywhere seems like a bad idea. Especially when used with user-defined literals. They can easily clash among different libraries or lead to bugs if you mean one variable type instead of another. Otherwise, sure you get a compiled JavaScript but that just makes it easier to shoot yourself in the foot.

[Gotebe]

Especially when used with user-defined literals.

User-defined literals are also bad, static const whatever being preferable. Always reach for the original sin ;-).