On 03/25/2011 06:13 AM, Rodrigo Rivas wrote:
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.
Could you update your patch to match the final wording?
Thanks,
Jason
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
On Fri, Mar 25, 2011 at 5:01 PM, Rodrigo Rivas
wrote:
> 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 presen
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 Fri, Mar 25, 2011 at 2:51 PM, Rodrigo Rivas
wrote:
> 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
You were earlier talking about some "unified concept"; weren't you?
Now, i
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:22 AM, Rodrigo Rivas
wrote:
> 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
On Fri, Mar 25, 2011 at 8:56 AM, Rodrigo Rivas
wrote:
> 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.
Boost.Range is a library component.
> There has been some
On 25 March 2011 14:22, Rodrigo Rivas wrote:
> 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
>> f
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 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 7:27 AM, Rodrigo Rivas
wrote:
> 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
On 25 March 2011 12:27, Rodrigo Rivas wrote:
>
> IMO, this goes beyond the syntactic sugar that the range-for provides.
> It is about specifying a unified 'range' concept. The range-for is
> just the first, highly visible, user of this implicit specification.
Yes but it's too late to specify it in
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
N.B. I'm going to use the term "good old for" instead of "plain old for" ;-)
On 25 March 2011 11:43, Rodrigo Rivas wrote:
> 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 fun
> 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: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:
Let's say that I want to imitate 'exactly' the behavior of the
range-for, but with a plain old for (there are plenty of reasons for
that):
Note that there was already a special case for arrays.
Jason
On Fri, Mar 25, 2011 at 5:13 AM, Rodrigo Rivas
wrote:
> 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
On Fri, Mar 25, 2011 at 11:13 AM, Rodrigo Rivas
wrote:
> 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
On 25 March 2011 10:13, Rodrigo Rivas wrote:
>
> 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 say that I want to imitate 'exactly' the behavior of the
> range-for, but wi
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
>> 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 17 March 2011 20:10, Jonathan Wakely wrote:
> On 17 March 2011 20:00, Rodrigo Rivas wrote:
>>> Yes, I was just trying exactly that improvement.
>> How about this?
>
> Nice. The comments should be changed too:
>
> If RANGE_EXPR is an array:
> BEGIN_EXPR = __range
> END_EXPR = __ran
On 17 March 2011 20:00, Rodrigo Rivas wrote:
>> Yes, I was just trying exactly that improvement.
> How about this?
Nice. The comments should be changed too:
If RANGE_EXPR is an array:
BEGIN_EXPR = __range
END_EXPR = __range + ARRAY_SIZE(__range)
Else if __range.begin() or __r
> 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
On 17 March 2011 19:40, Rodrigo Rivas wrote:
> 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,
Yes
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
On 17 March 2011 18:29, Rodrigo Rivas wrote:
>> 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 shoul
On 17 March 2011 18:26, Rodrigo Rivas wrote:
> 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
> 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)
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 :-(
On 17 March 2011 18:18, Jonathan Wakely wrote:
> On 17 March 2011 18:09, Rodrigo Rivas wrote:
>> 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
On 17 March 2011 18:09, Rodrigo Rivas wrote:
> 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 de
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
35 matches
Mail list logo
