This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: conversions between vectors
Aldy Hernandez <aldyh@redhat.com> writes:
| >>>>> "Joseph" == Joseph S Myers <jsm28@cam.ac.uk> writes:
|
| > On 21 Dec 2001, Aldy Hernandez wrote:
| >> "vector signed int". Also, assignments between "signed int" and
| >> "unsigned int" are allowed even in pedantic mode. So, IMO the above
|
| > And this (implict signed/unsigned conversions) is a source of security
| > holes.
Completely agreed.
| But it follows C semantics. You are allowed to copy signed int to
| unsigned int without any warnings of any kind.
Well, the C definition certainly allows a warning in such cases.
[...]
| > The correspondence with valarrays was to some extent because those are a
| > well-developed set of semantics known to work. Start by documenting in
| > the manual the correspondence with valarrays and, for C programmers, what
| > this means, and what parts of it are implemented. Only then propose
| > specific extensions, with precise documentation for what they mean and
| > when they are allowed, and justification in each case.
|
| The correspondence is minimal IMO.
That correspondance is minimal only because you're insisting to keep
to separate, and to some extent incompatible implementations, for the
same concept.
| Valarrays are vectors of any type
| (including arrays and aggregate types). Vectors are merely vectors of
| the base types (char, int, short, float, double).
Err... Valarray<> are arrays of any type that *behaves like* fundamental
types.
| Valarrays allow
| overloaded arithmetic between them. Vectors do not.
And it is questionnable why vectors should not.
| Valarrays allow vectors of vectors.
Wrong. Valarray< valarray<> > is formally prohibited. However, I
made the extra effort to allow it because it was repeatedly requested
-- and I don't see any strong reason to disallow it.
| Vectors do not. Valarrays do not allow casts
| between vectors. Vectors do.
And when they do, I suspect it construct a new vector. But then in,
there is no real difference with respect to the machinery provided by
C++: You just invoke valarray<>::apply() withe the right functional
object. Or, you can std::trsnsform().
| Compatability with valarray is a nice thought, but I don't think it's
| quite relevant.
I disagree; compatibility with valarray<> is not a theoritical
issue. It stems from providing functionnalities we want to have in C
without dumping all the C++ features.
| In documenting valarrays and C-vectors, we'll find
| more differences than similarities.
Then, feel free to raise the issue and I'll try to provide insites
based on my understanding of valarray<>.
-- Gaby