Usage of "auto". What for?

[Guest]

I currently get asked about my usage of "auto". What is it for?
The keyword is clearly superflous here.

In contrast to the huge majority of C/C++ developers I write
definitions very explicitly like that:

int main(char argc, char *argv[], char *env[]) {
try {
auto Exception mainException(1);
mainException.setErrNo(42);
} catch (Exception caughtException) {
std::cout << "caught caughtException:" << caughtException.errNo <<
std::endl;
}
}

Of course you do not need the keyword auto to make the program
compile, link and run.
On the other hand, you (more clearly parsers) gain easy information
about where definitions are made !

As a plain developer reading his C++ file in an editor with the
indention used above it is mor ease to remember, that the auto
variables will be deconstructed, when going out of scope.

The other thing is, that you can use code parsers more easily to
process ascpects of variable usage for example.

 

[Sylvester Hesp]

I currently get asked about my usage of "auto". What is it for?
The keyword is clearly superflous here.

In contrast to the huge majority of C/C++ developers I write
definitions very explicitly like that:

Then you're in for a treat:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1984.pdf

Have fun rewriting your code once you switch to C++09

- Sylvester

 

[Guest]

At first sight I am really horrified.

Seems the principals of C++ are not at all interested in having a
stable language.
I.m.h.o. this is one reason ( in addition to the lack of an ABI
standards to allow for exchange of C++ binary libraries plus
headers ), why C++ looses followers against languages as C# for
example.
The less protection of development efforts by the standard, the more
readily you change.

A small community of indicate the downgrade of a language.
Of course there is middle-technology to connect the different
languages.

But there is an infrastructure around software development
( languages ) that is not solved by connective techniques, like
programmers, libraries, tools, discussions, ...

The idea of changing semantics and syntax of existing language
features is - to express it very politely - not necessariliy to the
advantage of the language.

 

[Sylvester Hesp]

At first sight I am really horrified.

Seems the principals of C++ are not at all interested in having a
stable language.
I.m.h.o. this is one reason ( in addition to the lack of an ABI
standards to allow for exchange of C++ binary libraries plus
headers ), why C++ looses followers against languages as C# for
example.

I don't agree. C++ looses followers because C++ doesn't evolve as rapidly as
Java and C#. Besides, this very same auto feature will also makes it way
into C# 3.0, so according to your reasoning those who went to code C# will
also stop using C# for the very same reason they left C++.

And yes, you can misuse the new 'auto' feature just as you can misuse many
of the C++ features, but it's definitely a gain for those who deal with lots
of generic code and deeply nested template types. I, for one, am happy of
the new feature. I'm tired of writing std::vector<int>::iterator every time
while it's very obvious that if I call begin() on a vector it returns that
very same type (and this is just a mild nuisance).

- Sylvester

 

[Gavin Deane]

At first sight I am really horrified.

Seems the principals of C++ are not at all interested in having a
stable language.
I.m.h.o. this is one reason ( in addition to the lack of an ABI
standards to allow for exchange of C++ binary libraries plus
headers ), why C++ looses followers against languages as C# for
example.
The less protection of development efforts by the standard, the more
readily you change.

A small community of indicate the downgrade of a language.
Of course there is middle-technology to connect the different
languages.

But there is an infrastructure around software development
( languages ) that is not solved by connective techniques, like
programmers, libraries, tools, discussions, ...

The idea of changing semantics and syntax of existing language
features is - to express it very politely - not necessariliy to the
advantage of the language.

You said yourself that your use of the auto keyword is in contrast to
the huge majority of C/C++ developers. For my part I have never once
seen it used in code and you are the first person I have ever
encountered, either online or in the real world, who uses it. If the
proposal were to change the meaning of a keyword like "class" or "if",
clearly that would be mad. There would be very little C++ code
unaffected. But auto in its current form has precisiely zero effect on
the compiler and is almost universally ignored by C++ programmers.
It's at the very top of the pointless keywords list, above even
register and inline. Given all that, while the general principle of
redefining the meaning of a keyword is quite alarming, in this
specific case I think the potential benefits of introducing a useful
capability that also exists (or will exist) in a competing language
outweigh the costs, which are extremely close to zero across the C++
world.

Gavin Deane

 

[=?iso-8859-1?q?Kirit_S=E6lensminde?=]

Then you're in for a treat:http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1984.pdf

Oh I can't wait for this!

There are times that I've written a templated function as it was
easier than trying to work out the correct type of an iterator or some
other deeply nested type.


K

 

[Joe Gottman]

Then you're in for a treat:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1984.pdf

Have fun rewriting your code once you switch to C++09

He won't have to. The present meaning of auto will be preserved; it
will just have another, much more useful, use. It will be like the many
different ways of using the "static" keyword.

Joe Gottman

 

[Sylvester Hesp]

He won't have to. The present meaning of auto will be preserved; it
will just have another, much more useful, use. It will be like the many
different ways of using the "static" keyword.

Interesting, do you have a source to back that up? Because if you read that
paper I just linked to, or the latest C++09 draft
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf), you
will see that the 'auto' storage specifier has been removed.

- Sylvester Hesp

 

[Sylvester Hesp]

Interesting, do you have a source to back that up? Because if you read
that paper I just linked to, or the latest C++09 draft
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf), you
will see that the 'auto' storage specifier has been removed.

- Sylvester Hesp

Besides, it would make sense to remove it. Rather than with 'static', the
new usage for 'auto' is used in exactly the same context as the old usage,
which can conflict with eachother:

typedef int foo;
void bar(int i)
{
auto foo(i); // #1
}

What is the meaning of the statement at #1? Is it a definition of a local
variable i of type int, that has automatic storage duration? Or is it a
definition of a local variable foo, initialized with the int i, where it's
type is deduced from it's initialization? Currently, it is the former. But
after N1984 is implemented, it is the latter. You can't keep the former use
of auto alive because that will result in ambiguities in the language.

- Sylvester Hesp

 

[Clark Cox]

At first sight I am really horrified.

[at the C++09 semantics of the auto keyword]

The idea of changing semantics and syntax of existing language
features is - to express it very politely - not necessariliy to the
advantage of the language.

I would agree with you if it weren't for the fact that the auto
keyword, as it exists, is completely useless. It effectively has *no
semantics to change*. Anyone currently using it in any real code is,
IMHO, simply being different for difference's sake.

 

[Greg Herlihy]

Interesting, do you have a source to back that up? Because if you read that
paper I just linked to, or the latest C++09 draft
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf), you
will see that the 'auto' storage specifier has been removed.

The auto specifier (along with its automatic type deduction capability) is
described in §7.1.5.4 of n2134 (the latest draft C++ Standard).

Joe is correct: the existing semantics of auto are preserved so no code
changes will be necessary as a consequence of this new use for the auto
keyword.

Greg

 

[Greg Herlihy]

Besides, it would make sense to remove it. Rather than with 'static', the
new usage for 'auto' is used in exactly the same context as the old usage,
which can conflict with eachother:

typedef int foo;
void bar(int i)
{
auto foo(i); // #1
}

What is the meaning of the statement at #1? Is it a definition of a local
variable i of type int, that has automatic storage duration?

Yes. Note that the local variable "i" hides the parameter that is also named
"i" - which is unlikely to be intentional. In fact, the usual syntax for a
declaration of this sort would be:

auto foo i;

Now, the name conflict with the "i" parameter is apparent.

Or is it a
definition of a local variable foo, initialized with the int i, where it's
type is deduced from it's initialization?

No. Since "foo" is a typedef name it may not also be a function name. And
since the type is supplied in this declaration, no automatic type deduction
needs to take place. So the meaning of this confusing declaration will be
just as confusing (and will mean the same thing) in C++09 as it does in
C++03.

Currently, it is the former. But
after N1984 is implemented, it is the latter. You can't keep the former use
of auto alive because that will result in ambiguities in the language.

No, as long as the use of "auto" is legal in C++03, then that same use of
"auto" will have the same meaning in C++09. In other words, any use of auto
to perform automatic type deduction in C++09, will not compile under the
current C++ Standard because omitting the type from a type declaration is
currently not legal.

Greg

 

[James Kanze]

Then you're in for a treat:http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1984.pdf

Have fun rewriting your code once you switch to C++09

If you actually read the proposal, you'll find that it goes to
some pains to avoid breaking existing code. Whether his use is
a good idea or not, it will remain legal.

 

[James Kanze]

At first sight I am really horrified.

Read the proposal carefully. It goes to great pains to avoid
breaking existing code.

Seems the principals of C++ are not at all interested in having a
stable language.

Breaking existing code is considered a serious problem by the
committee. Breaking large bodies of existing code is sufficient
to prevent a proposal from being adopted. And while the
majority of C++ users may not use auto, you are not alone in
your preferences, and there is a significant body of code which
uses it. A proposal which would break such code would not stand
a chance of being adopted.

[...]

The idea of changing semantics and syntax of existing language
features is - to express it very politely - not necessariliy to the
advantage of the language.

I think that the majority of the committee would agree with you
here. There's no point in having a standard if standard
conforming code ceases to be legal a couple of years down the
road.

The proposal in question doesn't change the semantics of
existing code. It defines semantics for code which would not
currently be legal. Thus (according to proposal):

auto int i ; // Works as always...
auto j = i ; // Currently illegal, the proposal
// makes it legal, and defines
// semantics for it.

 

[James Kanze]

I currently get asked about my usage of "auto". What is it for?
The keyword is clearly superflous here.

In contrast to the huge majority of C/C++ developers I write
definitions very explicitly like that:

int main(char argc, char *argv[], char *env[]) {
try {
auto Exception mainException(1);
mainException.setErrNo(42);
} catch (Exception caughtException) {
std::cout << "caught caughtException:" << caughtException.errNo <<
std::endl;
}
}

Of course you do not need the keyword auto to make the program
compile, link and run.
On the other hand, you (more clearly parsers) gain easy information
about where definitions are made !

As a plain developer reading his C++ file in an editor with the
indention used above it is mor ease to remember, that the auto
variables will be deconstructed, when going out of scope.

The other thing is, that you can use code parsers more easily to
process ascpects of variable usage for example.

It's a very good idea per se. It just has one major problem: no
one is using it. The result is that anyone reading your code
will wonder what is going on. It should have been required from
the beginning, in C. Or rather, C should have defined a
declaration syntax that was clear, and which worked, rather than
the mess we've inherited. But it's far too late to change that
now.

 

[Juha Nieminen]

Oh I can't wait for this!

There are times that I've written a templated function as it was
easier than trying to work out the correct type of an iterator or some
other deeply nested type.

I have sometimes done that too. For example, I once wrote a small
program where I made a function which calls another function. I wanted
to make that other function be a parameter so that I can call the
first function and tell it which other function it should call. Even
though all those alternative functions had the same form, I would still
not be bothered by trying to remember how to write a function pointer
syntax, so I simply made it a template parameter to the first function
and let the compiler figure it out.

By the way, what will this do:

void foo(auto x) { ... }

Will that be equivalent to:

template<typename T>
void foo(T x) { ... }

?

 

[Sylvester Hesp]

If you actually read the proposal, you'll find that it goes to
some pains to avoid breaking existing code. Whether his use is
a good idea or not, it will remain legal.

I have not read the proposal fully - while browsing through the proposed
wording, I saw that they removed 'auto' from the storage class specifiers in
7.1.1, which made me believe the old behaviour of auto would disappear. My
bad.

- Sylvester Hesp

 

[Sylvester Hesp]

Yes. Note that the local variable "i" hides the parameter that is also
named
"i" - which is unlikely to be intentional. In fact, the usual syntax for a
declaration of this sort would be:

auto foo i;

Of course, but I had to think of a possible conflict, the above statement is
not ambiguous in any way

No. Since "foo" is a typedef name it may not also be a function name.

I take it you mean 'variable name'? And why not? It just locally hides the
global typedef, which always has been legal in C++.

And
since the type is supplied in this declaration, no automatic type
deduction
needs to take place. So the meaning of this confusing declaration will be
just as confusing (and will mean the same thing) in C++09 as it does in
C++03.


No, as long as the use of "auto" is legal in C++03, then that same use of
"auto" will have the same meaning in C++09. In other words, any use of
auto
to perform automatic type deduction in C++09, will not compile under the
current C++ Standard because omitting the type from a type declaration is
currently not legal.

Right, to recap: so while this is legal:

typedef int foo;
void bar(float i)
{
float foo(i); // hides ::foo
}

There is no corresponding declaration using automatic type deduction,
because the use of 'foo' in 'auto foo(i)' would make it a declaration of
variable 'i' of type 'foo' (thus int) with automatic storage duration,
rather than a declaration of variable 'foo' that is initialized with 'i'
with automatic type deduction (thus float). And we can't use 'auto foo = i',
because that is ill-formed because the omission of a variable name, even
though it *could* be parsed as a declaration with automatic type deduction,
but it isn't parsed that way, because foo is a type.

Is this correct?

- Sylvester Hesp

 

[Thomas J. Gritzan]

Juha Nieminen schrieb:
[...]

By the way, what will this do:

void foo(auto x) { ... }

Will that be equivalent to:

template<typename T>
void foo(T x) { ... }

?

Surely not. I did not found anythink in the proposal, but logically it
would only be legal with a default argument:

void foo(auto x = MyClass()) { ... }

which is:

void foo(MyClass x = MyClass()) { ... }

 

[Doctor Smith]

The "auto" keyword is not yet part of the C++ language. The document
Sylvester referred to is related to a proposal for the next revision
of the C++ standard. So, currently, it should strictly be treated as
a compiler-specific language extension. Therefore, to understand what
"auto" does in your case, you need to refer to your compiler's
documentation.