> bug 2645 concerns silently ignoring cv qualifiers on reference types
> introduced via typedefs or template type args see [8.3.2]
> Question. Should we apply the same logic to restrict on non-pointer/reference
> types also introduced via typedefs or template type args?
IMO, no. "const" implies a property which reference types already have, so
it's reasonable to ignore it. __restrict__ implies a property which only
pointers can have, so getting another kind of type is probably a bug.
Jason
| Hi,
| bug 2645 concerns silently ignoring cv qualifiers on reference types
| introduced via typedefs or template type args see [8.3.2]
| Question. Should we apply the same logic to restrict on non-pointer/reference
| types also introduced via typedefs or template type args?
|
| The standard says
| typedef int &ref_t;
| ref_t const thing = i;
| is legal, and thing has type `int &'. so, should
| typedef int i_t;
| i_t __restrict__ thing;
| be legal with thing having type `int'?
Yes, that is consistent semantics with the rest of cv-qualifiers.
-- Gaby
CodeSourcery, LLC http://www.codesourcery.com
| >>>>> "Nathan" == Nathan Sidwell <nat...@codesourcery.com> writes:
|
| > bug 2645 concerns silently ignoring cv qualifiers on reference types
| > introduced via typedefs or template type args see [8.3.2]
| > Question. Should we apply the same logic to restrict on non-pointer/reference
| > types also introduced via typedefs or template type args?
|
| IMO, no. "const" implies a property which reference types already have, so
| it's reasonable to ignore it.
I don't agree. The description given by Nathan applies as well to
volatile.
typedef int &ref_t;
ref_t volatile thing;
though it does seem reasonable to reject restrict on non-pointers.
nathan
--
Dr Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery LLC
'But that's a lie.' - 'Yes it is. What's your point?'
nat...@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nat...@acm.org
> __restrict__ implies a property which only pointers can have
references might be decorated with __restrict__ too, I suppose. Not
in C99, of course, but perhaps in the next C++ standard? It does make
sense to me.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me
The standard says
typedef int &ref_t;
ref_t const thing = i;
is legal, and thing has type `int &'. so, should
typedef int i_t;
i_t __restrict__ thing;
be legal with thing having type `int'?
nathan
I consider the fact that volatile is silently ignored here to be a bug.
A helpful compiler would issue a diagnostic.
I don't know exactly why the committee decided to treat volatile the
same way as const here, but it may have been because they didn't consider
it, or didn't think it important.
But even though the committee didn't mandate a diagnostic, I think good
quality compilers should issue one.
--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
>>>>> "Gabriel" == Gabriel Dos Reis <g...@codesourcery.com> writes:
>> I don't agree. The description given by Nathan applies as well
>> to volatile.
Jason> I agree with Fergus that this is unfortunate. But I
Jason> suppose I'd be happy to accept __restrict__ in this
Jason> situation with a warning.
Yes, that makes sense to me too. (Same goes for volatile, actually.)
If we're ignoring the qualifier, issue a plain warning; a pedwarn is
too strong because that will halt compilation.
--
Mark Mitchell ma...@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com