On 2010-05-07 09:52:46 -0400, "Robert Jacques" <sandf...@jhu.edu> said:
On Fri, 07 May 2010 07:51:11 -0400, Michel Fortin
<michel.for...@michelf.com> wrote:
On 2010-05-07 01:34:39 -0400, "Robert Jacques" <sandf...@jhu.edu> said:
And then there's the ambiguous case:
x[] = foo(y[]);
Which is an example of x[] = y; vs x[] = y[]; problem.
True. The problem comes from the overloaded meaning of []: "slice" or
"array op"? I'm not sure whether this is a problem or not. We already
have overloaded functions which can be ambiguous. The compiler solves
this with a compile-time error; perhaps it should be the same here.
True, but other overloaded function you can resolve by a) assigning to
a temporary of the desired type or b) using the qualified name. With
array ops I must using the [] operator and therefore must be ambiguous.
Or instead of generating an error, we could just give priority to array
ops. Since they use smaller temporaries (if at all), it makes sense to
prefer them whenever they work. Is there a case where you'd expect "x[]
= foo(y[])" to give you a different result whether it was done using
array ops or a temporary array?
And if you really want a temporary array, just do this:
auto tmp = foo(y[]);
x[] = tmp;
There is some elegance to that solution since it chooses the right
solution for the problem at hand. If you assign the result to a
temporary array as above, it's probably because you'll need it
somewhere else and thus you really need to keep the temporary around.
If you don't don't use a temporary variable, you'll automatically
benefit from array ops.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
