Re: "Almost Always Auto"

[Ian Collins]

Stefan Ram wrote:
> r...@zedat.fu-berlin.de (Stefan Ram) writes:
>> struct scanner
>> { auto ch = unsigned char {};
>> ... }
>
> Next, I tried it on a block:
>
> int main()
> { auto s = scanner {};
> ... }
>
> and immediately got (for the line »{ auto s = scanner {};«):
>
> internal compiler error: in gimplify_expr, at gimplify.c:8629
>
> from GCC 5.1.1. That's not fair!

Fixed in more recent versions.

--
Ian Collins

[Jorgen Grahn]

On Wed, 2016-01-13, Stefan Ram wrote:
> I just read a web page »Almost Always Auto« and wanted
> to give it a try.

http://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/

Watched a video of him speak about it today, and it occured to me that
if we go that way we'll regret it in a few years. The lack of
explicit typing was one main reason I abandoned Python -- the code
became too hard to read.

I /do/ use auto a lot, I'm grateful for it, and I may use it more in
the future (I only started writing C++11 code from scratch a month
ago) but I don't think I'll ever try to use it in the extreme.

And no, I won't switch to an IDE which tells me the types in my code,
nor will I ask my potential readers switch to one.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Juha Nieminen]

Stefan Ram <r...@zedat.fu-berlin.de> wrote:
> I just read a web page »Almost Always Auto« and wanted
> to give it a try.

I'd suggest the exact opposite principle: Almost never auto.

Strong typing is one of the advantages of C++, as it catches mistakes
at compile time (which is one of the best stages at which to catch
mistakes). If you have something like:

MyType result = foo();

and it turns out that foo() doesn't actually return a value that's
compatible with MyType, the compiler will immediately tell you. If you
used auto, the error message would much more obscure, and in a few cases
it could even compile but malfunction, which would be the worst possible
scenario (and something that's avoided by not using 'auto').

That's not to say that 'auto' is useless. On the contrary. It's extremely
useful. It's very useful in generic code, especially templated code.

It's also useful in non-generic code, but should be used there only when
it makes sense to use it. In general, in non-generic code it should/can be
used when it really is so that the actual type doesn't matter. This may be
in cases where the code just doesn't care what the type is, or when there
is some guarantee about the behavior of the type, but the exact name of the
type is irrelevant (iterators are a perfect example.)

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Wouter van Ooijen]

Op 18-Jan-16 om 10:59 AM schreef Juha Nieminen:

> Stefan Ram <r...@zedat.fu-berlin.de> wrote:
>> I just read a web page »Almost Always Auto« and wanted
>> to give it a try.
>
> I'd suggest the exact opposite principle: Almost never auto.
>
> Strong typing is one of the advantages of C++, as it catches mistakes
> at compile time (which is one of the best stages at which to catch
> mistakes). If you have something like:
>
> MyType result = foo();
>
> and it turns out that foo() doesn't actually return a value that's
> compatible with MyType, the compiler will immediately tell you. If you
> used auto, the error message would much more obscure, and in a few cases
> it could even compile but malfunction, which would be the worst possible
> scenario (and something that's avoided by not using 'auto').

OTOH, if foo() returns something that can be converted to a MyType yours
statement will do so silently, which I dislike.

> That's not to say that 'auto' is useless. On the contrary. It's extremely
> useful. It's very useful in generic code, especially templated code.

IMO auto is usefull in almost all code. When your code silently
malfunctions because the thing that foo() returns is not what you
expected but still has the same methods/signatures there is something
seriously wrong.

> It's also useful in non-generic code, but should be used there only when
> it makes sense to use it. In general, in non-generic code it should/can be
> used when it really is so that the actual type doesn't matter. This may be
> in cases where the code just doesn't care what the type is, or when there
> is some guarantee about the behavior of the type, but the exact name of the
> type is irrelevant (iterators are a perfect example.)

IMO nearly all code is an example of what you describe. The only reason
for *not* using auto is that you defintely need a specific type, which
should be rare.

Wouter van Ooijen

[Paavo Helde]

On 18.01.2016 19:55, Wouter van Ooijen wrote:
> Op 18-Jan-16 om 10:59 AM schreef Juha Nieminen:

>> I'd suggest the exact opposite principle: Almost never auto.

> IMO auto is usefull in almost all code.

auto should be used if it makes the code more readable and more
understandable as the alternatives, and vice versa. It's as simple as that.

Cheers
Paavo

[Scott Lurndal]

Wouter van Ooijen <wou...@voti.nl> writes:
>Op 18-Jan-16 om 10:59 AM schreef Juha Nieminen:
>

>IMO nearly all code is an example of what you describe. The only reason
>for *not* using auto is that you defintely need a specific type, which
>should be rare.

Actually, it's not rare at all in embedded programming, systems programming and in programming
simulations of physical processors and other hardware elements to require
a type with specific size and alignment characteristics.

[Jorgen Grahn]

On Mon, 2016-01-18, Juha Nieminen wrote:
> Stefan Ram <r...@zedat.fu-berlin.de> wrote:
>> I just read a web page »Almost Always Auto« and wanted
>> to give it a try.
>
> I'd suggest the exact opposite principle: Almost never auto.

Isn't it funny -- and sad -- how an obviously useful feature such as
this one opens up a can of worms?

I probably use 'auto' more than you do at this point, but I can easily
imagine a future where some people write code which others (like me)
reject as unreadable. As if we're not our own worst enemies already ...

[Wouter van Ooijen]

Op 18-Jan-16 om 8:03 PM schreef Scott Lurndal:

It embedded it is very common to have hardware registers of specific
size and address, but you won't find them defined and at the same moment
initialized from some expressing. In embedded too, it is very likely
that you want to store the result of an expression in a variable of the
appropriate type, that is: the type of the expression.

There are of course plenty exceptions. For instance,

for( auto i = 0; i < 200; i++ )...

is not a wise line to write when you are (also) targeting 8-bit chips,
that can handle an byte much more efficient yet have '0' as (16-bit)
int. More appropropriate is

for( uint_fast8_t i = 0; ....

Or even better: some way to select the index type automatically based on
the upper limit.

Wouter van Ooijen

[Vir Campestris]

On 18/01/2016 17:55, Wouter van Ooijen wrote:
> OTOH, if foo() returns something that can be converted to a MyType yours
> statement will do so silently, which I dislike.

I use auto when I have to, and only then.

If foo returns something that can be converted to a MyType I'll probably
have done it on purpose. If I store foo in an auto, then later try to
stuff that in an STL type I'm into template error message madness - and
not at the point of the call to foo.

Andy

[Öö Tiib]

On Monday, 18 January 2016 21:12:42 UTC+2, Jorgen Grahn wrote:
> On Mon, 2016-01-18, Juha Nieminen wrote:
> > Stefan Ram <r...@zedat.fu-berlin.de> wrote:
> >> I just read a web page »Almost Always Auto« and wanted
> >> to give it a try.
> >
> > I'd suggest the exact opposite principle: Almost never auto.
>
> Isn't it funny -- and sad -- how an obviously useful feature such as
> this one opens up a can of worms?
>
> I probably use 'auto' more than you do at this point, but I can easily
> imagine a future where some people write code which others (like me)
> reject as unreadable. As if we're not our own worst enemies already ...

It is art like any other. If I feel a need to hover mouse over auto
variable to find out what its type is then it apparently slows down my
reading of code. On the other hand if there is stutter like that then
it is annoying:

std::shared_ptr<IconicNode> iconicNode = std::make_shared<IconicNode>();

[Martin Shobe]

I mostly agree with the above. I also use it when the type is already
obvious. For example

auto foo = new bar{};

Martin Shobe

[Juha Nieminen]

Jorgen Grahn <grahn...@snipabacken.se> wrote:
> On Mon, 2016-01-18, Juha Nieminen wrote:
>> Stefan Ram <r...@zedat.fu-berlin.de> wrote:
>>> I just read a web page »Almost Always Auto« and wanted
>>> to give it a try.
>>
>> I'd suggest the exact opposite principle: Almost never auto.
>
> Isn't it funny -- and sad -- how an obviously useful feature such as
> this one opens up a can of worms?
>
> I probably use 'auto' more than you do at this point, but I can easily
> imagine a future where some people write code which others (like me)
> reject as unreadable. As if we're not our own worst enemies already ...

Use 'auto' when it actually serves a useful purpose (eg. in generic code),
or when it's actually useful in some other way. Use it to save typing only
in rare, very specific circumstances (eg. with iterators, or in some
range-based for loops).

In normal usage, however, the only thing that 'auto' does is to circumvent
the strong typing system, which isn't always a good thing.

[Jorgen Grahn]

On Mon, 2016-01-25, Juha Nieminen wrote:
> Jorgen Grahn <grahn...@snipabacken.se> wrote:
>> On Mon, 2016-01-18, Juha Nieminen wrote:
>>> Stefan Ram <r...@zedat.fu-berlin.de> wrote:
>>>> I just read a web page »Almost Always Auto« and wanted
>>>> to give it a try.
>>>
>>> I'd suggest the exact opposite principle: Almost never auto.
>>
>> Isn't it funny -- and sad -- how an obviously useful feature such as
>> this one opens up a can of worms?
>>
>> I probably use 'auto' more than you do at this point, but I can easily
>> imagine a future where some people write code which others (like me)
>> reject as unreadable. As if we're not our own worst enemies already ...
>
> Use 'auto' when it actually serves a useful purpose (eg. in generic code),
> or when it's actually useful in some other way. Use it to save typing only
> in rare, very specific circumstances (eg. with iterators, or in some
> range-based for loops).

Happily, I think people agree so far ...

> In normal usage, however, the only thing that 'auto' does is to circumvent
> the strong typing system, which isn't always a good thing.

You should probably clarify that last part ... typing is still strong
if you use 'auto', so I think you really want to describe some other
problem.

C++ with auto is (it seems to me) more like type inference in languages
like Standard ML or Haskell, not like duck typing in Python. There /is/
a real type behind the 'auto' -- the only issue is if the reader gets enough
useful information about it, without seeing it spelled out.

[Alf P. Steinbach]

On 1/25/2016 3:21 PM, Jorgen Grahn wrote:
>
> C++ with auto is (it seems to me) more like type inference in languages
> like Standard ML or Haskell, not like duck typing in Python.

C# “var” comes to mind.

https://msdn.microsoft.com/en-us/library/bb383973.aspx


Cheers,

- Alf

[David Brown]

Python also has strong typing. A key difference between "auto" in C++
and Python is that in C++, with "auto x = foo()", /x/ is the object with
the fixed type. In Python, with "y = foo()", /y/ is an identifier bound
to a nameless object with fixed type. y can be re-bound to any other
object of any type, unlike x.

"Duck typing" refers more to how types are classified. In C++, classes
are organised by inheritances - you can use an object in a particular
way if it or one of its ancestors is of a particular type. In Python,
you can use an object in a particular way if it has the appropriate
member. Python duck typing is more akin to templates in C++.

C++11 gives you much of the convenience of Python (by using auto rather
than spelling out the type every time), while retaining the safety of
static type checking in C++. Note that this is not about "strong
typing" or "type safety", as Python has these - it is about static or
compile-time checking of types rather than at run-time.

[Jorgen Grahn]

On Mon, 2016-01-25, David Brown wrote:
> On 25/01/16 15:21, Jorgen Grahn wrote:
>> On Mon, 2016-01-25, Juha Nieminen wrote:
...
>>> In normal usage, however, the only thing that 'auto' does is to circumvent
>>> the strong typing system, which isn't always a good thing.
>>
>> You should probably clarify that last part ... typing is still strong
>> if you use 'auto', so I think you really want to describe some other
>> problem.
>>
>> C++ with auto is (it seems to me) more like type inference in languages
>> like Standard ML or Haskell, not like duck typing in Python. There /is/
>> a real type behind the 'auto' -- the only issue is if the reader gets enough
>> useful information about it, without seeing it spelled out.
>
> Python also has strong typing.

Yes; I'm probably talking about "static typing", and maybe that was
what Juha N. wanted to say, too.

[snip description]

[David Brown]

That makes more sense, at least regarding Python. But "auto" in C++ is
still static typing - it is just not necessarily explicit typing. If
you write "auto x = 123;", then "x" is statically typed as an "int" -
you can't assign a pointer or a string to it. And the static type used
for the "auto" variable comes directly from its initialiser - if the
initialiser's type is clear, then the type of the "auto" variable is
equally clear without the programmer having to duplicate the same
information.

So "auto" is not really circumventing either the strong typing system,
or the static typing system - it is merely reducing the verbosity of the
code. Clearly you can't use "auto" in cases where you don't have the
initialiser (or function definition) on hand, such as for exported data
or class definitions - but in most cases where you /can/ use auto, it
does a fine job without losing any of the strengths of C++.

[Jorgen Grahn]

On Wed, 2016-01-27, David Brown wrote:
> On 27/01/16 02:08, Jorgen Grahn wrote:
>> On Mon, 2016-01-25, David Brown wrote:
>>> On 25/01/16 15:21, Jorgen Grahn wrote:
>>>> On Mon, 2016-01-25, Juha Nieminen wrote:
>> ...
>>>>> In normal usage, however, the only thing that 'auto' does is to circumvent
>>>>> the strong typing system, which isn't always a good thing.
>>>>
>>>> You should probably clarify that last part ... typing is still strong
>>>> if you use 'auto', so I think you really want to describe some other
>>>> problem.
>>>>
>>>> C++ with auto is (it seems to me) more like type inference in languages
>>>> like Standard ML or Haskell, not like duck typing in Python. There /is/
>>>> a real type behind the 'auto' -- the only issue is if the reader gets enough
>>>> useful information about it, without seeing it spelled out.
>>>
>>> Python also has strong typing.
>>
>> Yes; I'm probably talking about "static typing", and maybe that was
>> what Juha N. wanted to say, too.
>
> That makes more sense, at least regarding Python. But "auto" in C++ is
> still static typing - it is just not necessarily explicit typing.

Yes, and that's precisely what I was trying to convey above. I'm
familiar with the concepts: my first CS course, 26 years ago, used
Standard ML, where type inference works just like auto does in C++11.

(Just in case you were trying to educate me personally.)

...

> So "auto" is not really circumventing either the strong typing system,
> or the static typing system - it is merely reducing the verbosity of the
> code.

But it's not just about verbosity! Someone has to read -- and
understand -- the code, too ... more times than someone else has to
write it, hopefully.

Part of the reason I'm worried is the focus on the writers rather than
the readers.

[David Brown]

No, I was just trying to get the details clear, especially on the
differences between C++ auto and Python typing. (I agree that C++ auto
and ML are similar or even identical - but I am not familiar enough with
ML languages to be precise.)

>
> ...
>> So "auto" is not really circumventing either the strong typing system,
>> or the static typing system - it is merely reducing the verbosity of the
>> code.
>
> But it's not just about verbosity! Someone has to read -- and
> understand -- the code, too ... more times than someone else has to
> write it, hopefully.

That is why reducing verbosity is a good thing (as long as it does not
reduce clarity). You don't have to write out the type explicitly if it
is not needed, nor do you have to read it if it does not add anything to
your understanding of the code.

>
> Part of the reason I'm worried is the focus on the writers rather than
> the readers.
>

That is my focus is not on writers when saying that auto is good at
reducing verbosity. But I fully agree with you that being able to
/read/ the code easily is more important than being able to write it easily.