On 10/02/2010 01:50 PM, Rodrigo Rivas wrote:
I would change cp_parser_range_for to use cp_parser_decl_specifier_seq
instead of cp_parser_type_specifier_seq and then wait to complain about
defining a type until after we've seen the ':'.
I already tried that, but it didn't work. It seemed to me
Ah, yes. So we should share the parsing of the decl-specifier-seq with the
C-style for loop, which allows us to avoid the tentative parsing.
That was my original idea, but the C-style loop calls
cp_parser_simple_declaration(), that shouts at the ':'. So we should
either modify it to accept the
On 10/04/2010 10:59 AM, Rodrigo Rivas wrote:
Admittedly, this is not a trailing_return_type, but AFAICT it has
exactly the same restrictions.
The restrictions are slightly different; in the case of a trailing return
type a class-specifier is not one of the expansions, so we don't treat a {
as
Ah, yes. So we should share the parsing of the decl-specifier-seq with the
C-style for loop, which allows us to avoid the tentative parsing.
That was my original idea, but the C-style loop calls
cp_parser_simple_declaration(), that shouts at the ':'. So we should
either modify it to accept
On Mon, Oct 4, 2010 at 7:16 PM, Nicola Pero
nicola.p...@meta-innovation.com wrote:
I just implemented fast enumeration (ie, for (object in array) { ... })
for Objective-C, and I was now planning on doing it for Objective-C++ too. ;-)
If you're doing range-based for-loops for C++, we may as
2010/10/1 Jason Merrill ja...@redhat.com:
It took me some searching, but yes, it does:
A type-specifier-seq shall not define a class or enumeration unless it
appears in the type-id of an alias-declaration (7.1.3).
Normal declarations don't have a type-specifier-seq, they have a
On 09/20/2010 07:06 PM, Rodrigo Rivas wrote:
Are you sure? As I said in other post, I am no longer sure that the
C++0x draft forbids the type definition in this context.
But I'm no expert in standarese, so I'm still undecided.
It took me some searching, but yes, it does:
A type-specifier-seq
You do not need exceptions to implement what I said, just to return a
value. A boolean would suffice to detect whether you parsed a
definition.
Sure, I was talking generally.
The before whatever is hardcoded. And tentative parsing is
thoroughly abused in the parser.
Well, I tried to parse it
This is quite unreadable and not very informative.
Totally agree.
Here there are two problems...
snipped
I think that you are taking the wrong approach: you call
cp_parser_range_for with C++98 and then if such a loop is parsed
(the ':') you issue an error.
Maybe you should try to add the
On Mon, 2010-09-20 at 10:39 +0200, Rodrigo Rivas wrote:
This is quite unreadable and not very informative.
Totally agree.
Here there are two problems...
snipped
I think that you are taking the wrong approach: you call
cp_parser_range_for with C++98 and then if such a loop is parsed
Well, yes, this is true but there is still the issue that
void f() {
for(class C{};;)
;
}
generates the message
error: types may not be defined in range-based for loops
when compiled with -std=c++0x and no patches and that is odd since this
loop isn't range-based.
Oh, I see...
On second reading of the C++0x draft in cannot find any reason of what
the new type in range-fors should not be allowed.
Maybe someone can read it differently?
Regard.
Rodrigo
On 20 September 2010 20:19, Rodrigo rodrigorivasco...@gmail.com wrote:
Well, yes, this is true but there is still the issue that
void f() {
for(class C{};;)
;
}
generates the message
error: types may not be defined in range-based for loops
when compiled with -std=c++0x and no patches
The easy solution would be to remove the assignment to
type_definition_forbidden_message and then check for this case
particulary.
cp_parser_type_specifier_seq could return some indication of why the
parsing has failed or whether it has parsed a declaration. This is
much more useful than
On 21 September 2010 01:06, Rodrigo Rivas rodrigorivasco...@gmail.com wrote:
The easy solution would be to remove the assignment to
type_definition_forbidden_message and then check for this case
particulary.
cp_parser_type_specifier_seq could return some indication of why the
parsing has
Hello.
At the moment compilation of a range-based for in c++98 fails with the
error message:
foo.cpp: In function 'int foo()':
foo.cpp:4:13: error: expected initializer before ':' token
foo.cpp:6:1: error: expected primary-expression before '}' token
foo.cpp:6:1: error: expected ';' before
16 matches
Mail list logo
