On Thu, Mar 31, 2011 at 7:22 PM, Jason Merrill ja...@redhat.com wrote:
On 03/28/2011 08:28 PM, Rodrigo Rivas wrote:
A few comments:
1. I'm not sure about what should happen if the begin/end found in class
scope are not ordinary functions.
Whatever range.begin() would mean if written
On Tue, Mar 29, 2011 at 5:46 PM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
or new-style for loop?
Well, that is what they are called in Java, isn't it? And the syntax
is just the same, so it would make kind of sense.
But in the C++0x draft and the GCC docs it is almost always called
On Tue, Mar 29, 2011 at 11:13 PM, Jonathan Wakely jwakely@gmail.com wrote:
Thank you for your suggestions!
IMO, error cases 3 (hey, two 3s!), 4 and 6 are not so likely, as
including any STL container header will make a begin and an end
functions declared, though maybe not usabe. In these cases
On Sat, Mar 26, 2011 at 2:48 AM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
I see a core language specification, I see a third party library
implementation.
I don't see a unified concept.
I don't see it either. It's just a wish.
if it would add nothing, then we are in violent
On Wed, Mar 23, 2011 at 5:46 PM, Jason Merrill ja...@redhat.com wrote:
Yep. Here is the wording that we approved today:
[snip]
Nice. Thank you.
But now I'm a bit concerned about the complexity of this issue. Mind
me, I think that this solution is nice, but maybe it is a burden for
library
On Fri, Mar 25, 2011 at 11:52 AM, James Dennett james.denn...@gmail.com wrote:
I'd be interested to know those reasons.
Well, maybe not *plenty*, but *some*... Let's say that I have a function:
template typename S, typename T void Dump(S s, const T t)
{
for (auto i : t)
s.dump(i);
}
On 03/25/2011 11:13 AM, Rodrigo Rivas wrote:
Note that there was already a special case for arrays.
Yes, but std::begin/std::end are overloaded for arrays also, so the
library implementor would get the right behavior for free.
They are still vulnerable to the ADL issue, though.
--
Rodrigo
On Fri, Mar 25, 2011 at 11:27 AM, Jonathan Wakely jwakely@gmail.com wrote:
Or just don't use range-for, it's not essential (given the trouble
it's caused I'd quite happily have lived without it in C++0x!)
IMO, this goes beyond the syntactic sugar that the range-for provides.
It is about
On Fri, Mar 25, 2011 at 1:34 PM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
But what is that `unified range concept'? And why do we need it?
See Boost.Range for the concept and possibly uses. There has been some
discussion to accept it in the standard, IIRC.
Exactly. Which for me
On Fri, Mar 25, 2011 at 1:33 PM, Jonathan Wakely jwakely@gmail.com wrote:
Yes but it's too late to specify it in C++0x.
Boost.Range is the best place to work on that idea at present.
If/when it's fully baked I hope we'll see something like that in a
future TR or standard.
Agreed.
But
On Fri, Mar 25, 2011 at 7:50 PM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
Boost.Range is a library component.
True, but should it ever make its way to the standard library, it
would be good if it is consistent with the 'range' used by the
range-for. If not, we will have two subtly
On Fri, Mar 25, 2011 at 9:35 PM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
You were earlier talking about some unified concept; weren't you?
Now, it is shifting to library component.
With unified I meant that the same concept (range) is present both
in the core language and the
Hello all.
I've just read the paper titled Range-based for statements and ADL
by Jonathan Wakely and Bjarne Stroustrup at:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3257.pdf
The point of this article is that the argument dependent lookup in the
range-for specification will make
On Thu, Mar 17, 2011 at 7:18 PM, Jonathan Wakely jwakely@gmail.com wrote:
do you mind if I forward your mail to the committee reflector? The
fact that there's an implementation is useful.
I'd do that gladly... if only I'd know how...
The [1] reference in the cited paper requires
Actually, re-reading that and the following messages on the thread,
I'm wrong about the lookup being independent - if it only finds a
begin() member and no end() member it should still try to use r.end(),
and therefore give an error. It should not be possible to use
r.begin() and end(r)
I
Exactly what I had in mind!
You could also inhibit the member/non-member error message if any of
the lookups resulted in an error; and likewise inhibit the type
mismatch if this other one happened. But just now, it doesn't really
matter,
--
Rodrigo
Yes, I was just trying exactly that improvement.
How about this?
I'm going to let the committee know that option 5 has been
implemented. Thanks very much!
Cool! Thank you.
--
Rodrigo
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 9523fdc..aab9294 100644
--- a/gcc/cp/parser.c
+++
Nice. The comments should be changed too:
Sure. Also, should this ever be accepted, the std::begin() and
std::end() declarations should be removed from the header files.
On Fri, Mar 11, 2011 at 6:51 AM, Jason Merrill ja...@redhat.com wrote:
How about just calling maybe_constant_value call after the
fold_non_dependent_expr call in cp_parser_parenthesized_expression_list?
Well, I first tried something like this, but the key problem is the
*non_dependent* part, so
that should matter too much.
Regards
--
Rodrigo
Changelog:
gcc/cp/
2011-03-10 Rodrigo Rivas Costa rodrigorivasco...@gmail.com
* decl2.c (cp_check_const_attributes): New.
(cplus_decl_attributes): Call cp_check_const_attributes.
gcc/testsuite/
2011-03-10 Rodrigo Rivas Costa
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 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
I saw the flag situation after I sent my message. There must be a Keeper of
the Sacred Tree Flag Set
There are a few comments en tree.h about that, I if remember correctly...
I get the idea the real estate is at a premium and consuming flags could be
a problem.
Perhaps there is a context
I had to initialize the variable nested_being_defined to get it to compile
(possible uninitialized warning). I initialized it to false.
Ok, actually it is never used uninitialized, but let's get rid of the
warning.
I saw that it was never used uninitialized and was surprised gcc wasn't
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
3. The big one: Getting the integer(long long) and float(long double)
suffixes that are not used by gcc out of the preprocessor. Then we can
build the calls.
Just my two cents:
Add an output parameter to the function cpp_classify_number()
(libcpp/expr.c) to get the user-defined suffix.
It
I'm holding out for rolling back the lexer in some way that won't break
everything and emitting the (unrecognized by cpp ) suffix as a separate
identifier token. I'm thinking the cp_lexer_* routines or maybe a new one in
parser.c would be worth trying. Then the code I have now would just
I had to initialize the variable nested_being_defined to get it to compile
(possible uninitialized warning). I initialized it to false.
Ok, actually it is never used uninitialized, but let's get rid of the warning.
It looks like the first two are related. What does an enum look like in
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
Hello all.
This patch tries to implement the C++0x featue Forward declarations
for enums aka opaque enum declarations:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2764.pdf
Please note that this is a WIP, and as such lacks formatting,
comments, testcases, etc.
Except for the things
I'm looking at (besides input on what I've got currently):
So far I see it fine... except:
int len = TREE_STRING_LENGTH (strl);
should be:
int len = TREE_STRING_LENGTH (strl) - 1;
since the draft says its length excluding the terminating null character.
Also, I had to
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
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
Maybe Rodrigo would be interested in collaborating on this work?
Sure I am! Please, let me a couple of days to re-read the C++ draft,
and check this patch.
Also, take in account that I'm in no way a GCC expert... but I'll do my best.
Also I have a little patch on my own that might use some
35 matches
Mail list logo
