Applied (with a few formatting tweaks).
Thanks,
Jason
On 04/11/2011 04:50 PM, Rodrigo Rivas wrote:
Because the type of the expression must have complete type *only* if
it is an array.
Actually, if it has class type, it must also have a complete type or the
class member lookup is ill-formed. And you can't pass an expression of
void type to a
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 explicitly.
My guess is that if it is a function
(static or non-static) it is
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 31 March 2011 21:22, Rodrigo Rivas wrote:
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.
On 29 March 2011 01:49, Rodrigo Rivas wrote:
Hi again.
Here it is my first try at this. I have changed the list to
gcc-patches, I don't know if cross post would be correct.
Please, note that this patch is not finished: the new test cases are
still missing, and expect format mistakes,
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 29 March 2011 21:33, Rodrigo Rivas wrote:
On Tue, Mar 29, 2011 at 8:22 PM, Jonathan Wakely jwakely@gmail.com
wrote:
How about No suitable %begin% and %end% functions found for range
expression of type %qT in %for% statement ?
Nice.
But the problem here is that there are a lot of
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 03/25/2011 06:13 AM, Rodrigo Rivas wrote:
On Wed, Mar 23, 2011 at 5:46 PM, Jason Merrillja...@redhat.com 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
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 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 with a
On Fri, Mar 25, 2011 at 11:13 AM, Rodrigo Rivas
rodrigorivasco...@gmail.com wrote:
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.
On Fri, Mar 25, 2011 at 5:13 AM, Rodrigo Rivas
rodrigorivasco...@gmail.com wrote:
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.
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 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
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 james.denn...@gmail.com
wrote:
I'd be interested to know those reasons.
Well, maybe not *plenty*, but *some*... Let's say
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 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 7:27 AM, Rodrigo Rivas
rodrigorivasco...@gmail.com wrote:
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!)
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 25 March 2011 14:22, Rodrigo Rivas wrote:
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
On Fri, Mar 25, 2011 at 8:56 AM, Rodrigo Rivas
rodrigorivasco...@gmail.com wrote:
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.
On Fri, Mar 25, 2011 at 9:22 AM, Rodrigo Rivas
rodrigorivasco...@gmail.com wrote:
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
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 2:51 PM, Rodrigo Rivas
rodrigorivasco...@gmail.com wrote:
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
You were earlier
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
On Fri, Mar 25, 2011 at 5:01 PM, Rodrigo Rivas
rodrigorivasco...@gmail.com wrote:
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
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 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 dependent
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
The point
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
On 17 March 2011 18:26, Rodrigo Rivas wrote:
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]
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 should not
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 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, I
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
+++
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
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 = __range +
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.
44 matches
Mail list logo
