Mark Mitchell <[EMAIL PROTECTED]> writes:
| Chris Lattner wrote:
| >
| > On Apr 19, 2006, at 1:56 PM, Mark Mitchell wrote:
| >
| >> Let's accept that both the bit-preserving and value-preserving
| >> conversions would be useful. How do we differentiate the two?
| >>
| >
| >> For vectors, these operators would apply to each element, and then
| >> return a vector with the same number of elements as the input vector.
| >>
| >> I suppose that we could introduce these operators into C as well,
| >> although the pseudo-template syntax might not be as natural for C users.
| >
| > If you're interested in adding value for generic vectors, it may be
| > interesting to consider element access operations.
|
| Yes, I think that would be very useful to do.
|
| The original topic was specifically about casts, from a language-design
| perspective, so I was trying to answer that, but I'm glad to switch the
| conversation in the direction of what can we do to make it easier for
| people to get good use of generic vectors.
I agree with everything you have said. I suppose I'm a bit unclear
about this:
already defined. __value_cast<T> would just be an alias for
static_cast<T> for non-vector types, but for vector types it would do a
value-preserving conversion, even if C-style and static casts are
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
bit-preserving, for backwards compatibility.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
in particular the last sentence.
As for the language syntax, I don't think it would be that surprising
to C-users to introduce the infamous angle-bracket notation.
Alternatively, you could consider __value_cast(T, v) -- which is very
"macro"-like.
I'll notice that if you introduce the angle-backet notation in GNU C,
it would be a wonderful opportunity for libstdc++ people to share some
of the type traits machinery in C header files on GNU-C-based systems.
That consideration is, however, orthogonal to the original cast issue.
-- Gaby
