This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: conversions between vectors


On 22 Dec 2001, Aldy Hernandez wrote:

> But it follows C semantics.  You are allowed to copy signed int to
> unsigned int without any warnings of any kind.  You are allowed to
> send signed int into a function that expects unsigned int: no
> warnings.  This is C.  If we outlaw signed/unsigned compatability with
> vectors, then we have a hole in our language logic-- the rest of C
> won't care about signness, but vectors will ?!.

You can also assign between different integer sizes in C.  But if you are
assigning or passing pointers, you can't passed a pointer to signed where
one to unsigned is expected (though GCC will only warn in that case with
-pedantic).

> The correspondence is minimal IMO.  Valarrays are vectors of any type
> (including arrays and aggregate types).  Vectors are merely vectors of
> the base types (char, int, short, float, double).  Valarrays allow
> overloaded arithmetic between them.  Vectors do not.  Valarrays allow
> vectors of vectors.  Vectors do not.  Valarrays do not allow casts
> between vectors.  Vectors do.
> 
> Compatability with valarray is a nice thought, but I don't think it's
> quite relevant.  In documenting valarrays and C-vectors, we'll find
> more differences than similarities.

Valarrays tell you that you can't operate between vectors of different
lengths.  They tell you what types of operands you can operate on, with
vectors, and what type the results are.  (Appropriately extended to C -
for example, logical operators would in C yield a vector of int, as the
result type in C of logical operators, rather than bool.)

> And back to unsignedness, which is my original point.  Can someone
> provide a compelling reason why not to allow implicit unsigned and
> signed assigments-- in the spirit of the language?

They've turned out to be a bad idea.  The C type system is complicated,
C99 complicated it further (adding long long and complex types), and any
additions need to be done with very great care.  Are you sure these vector
extensions will never be used in safety-critical systems?  Implicit
non-value-preserving conversions are a source of complexity, and of risk
if everyone involved doesn't have a full understanding of the conversions,
what type everything has and where the conversions are applying.  At least
with valarray we have a design that has already been worked out and some
programmers may already understand - provided we follow it closely for the
rules about what operations can be used, when, and what the return types
are.

-- 
Joseph S. Myers
jsm28@cam.ac.uk


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]