This is the mail archive of the
mailing list for the GCC project.
Re: [C++0x PATCH] Remove auto as a storage class specifier
- From: "Lawrence Crowl" <crowl at google dot com>
- To: "Jakub Jelinek" <jakub at redhat dot com>
- Cc: "Andrew Pinski" <pinskia at gmail dot com>, "Doug Gregor" <doug dot gregor at gmail dot com>, "gcc-patches List" <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 6 Mar 2008 15:36:14 -0800
- Subject: Re: [C++0x PATCH] Remove auto as a storage class specifier
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <20080306232334.GL24887@devserv.devel.redhat.com>
On 3/6/08, Jakub Jelinek <firstname.lastname@example.org> wrote:
> On Thu, Mar 06, 2008 at 03:09:39PM -0800, Lawrence Crowl wrote:
> > On 2/28/08, Andrew Pinski <email@example.com> wrote:
> > > On Thu, Feb 28, 2008 at 2:20 PM, Doug Gregor <firstname.lastname@example.org> wrote:
> > > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2337.pdf
> > > >
> > > > Basically, the use of "auto" as a storage specifier is pretty rare,
> > > > and conflicts with the new meaning of "auto" in C++0x.
> > >
> > > So what if it is rare, it is breaking backwards compatibility even
> > > more. They should have used a new keyword instead but then again
> > > they know best, at least we hope they do.
> > Adding a new keyword would in all probability have introduced a
> > greater incompatibility than changing the meaning of auto because
> > programmers weren't using that word. I did a code search for auto,
> > and found 2/3 of all uses to be in compiler conformance tests.
> E.g. in glibc (which is written in GNU C, not C++) auto keyword is
> used heavily for nested function prototypes, to avoid warnings with
> void foo (void);
> void foo (void)
> // auto void bar (void);
> void bar (void)
> bar ();
> results in warning, with auto void bar (void); there are no warnings.
Um. Nested functions are non-standard C. The nested function does
have a prototype. It would seem that the warning is incorrect.
So, out of curiosity, why should the C++ committee support a work
around for an incorrect warning on an extension to the language?
What is the cost to users of doing so? What alternative would you
My suggestion is to fix the warning, and then remove the auto