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 s
On Thu, Mar 17, 2011 at 7:18 PM, Jonathan Wakely 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 authorization :-(
> 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)
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
+++ b/gc
>> 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 Wed, Mar 23, 2011 at 5:46 PM, Jason Merrill 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 implementors.
Let's
On Fri, Mar 25, 2011 at 11:52 AM, James Dennett wrote:
> I'd be interested to know those reasons.
Well, maybe not *plenty*, but *some*... Let's say that I have a function:
template void Dump(S &s, const T &t)
{
for (auto i : t)
s.dump(i);
}
Cool!
Now I want to do the following:
templ
> 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 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 specifying a unified 'r
On Fri, Mar 25, 2011 at 1:34 PM, Gabriel Dos Reis
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 means, it must be simple. Si
On Fri, Mar 25, 2011 at 1:33 PM, Jonathan Wakely 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 just now, how would
On Fri, Mar 25, 2011 at 7:50 PM, Gabriel Dos Reis
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 different definitions of
'range
On Fri, Mar 25, 2011 at 9:35 PM, Gabriel Dos Reis
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 standard library. And that i
On Sat, Mar 26, 2011 at 2:48 AM, Gabriel Dos Reis
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 agreement that we should
> no
> 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 help.
> 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 thin
> 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 c
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 usefu
> 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 par
> 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 ju
> 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
> t
> 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 con
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 s
2010/10/1 Jason Merrill :
> 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
> decl-specifier-seq.
> 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
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 well share ideas ;-)
Actual
30 matches
Mail list logo
