|
|
Glas :Re: [glas] MTL3 design ? [was MTL project site is up] |
From: David Abrahams (dave_at_[hidden])
Date: 2005-02-02 13:36:48
Toon Knapen <toon.knapen_at_[hidden]> writes:
> Jeremy Graham Siek wrote:
>> Hi Dave, Toon,
>> On Feb 1, 2005, at 3:55 PM, David Abrahams wrote:
>>
>>>> operator= for vectors does not require both vectors to have the same
>>>> size. Thus the lhs will be resized to the size of the rhs. But again
>>>> this poses a problem with stack-based objects because they can't be
>>>> resized. And why actually do you prefer to resize the lhs instead of
>>>> requiring that both vectors have the same size?
>>>
>>>
>>> I haven't given that question much thought yet, and I don't know
>>> Jeremy's rationale, but I can guess: stack objects with different
>>> sizes also have different types, so we can enforce incompatibility at
>>> compile-time.
>
> So since assigning stack-based vectors of different sizes produces a
> (compile-time) error, it is not unexpected that assigning a vector
> (heap-based or other) to a vector of a different size generates an error
> (compile-time or run-time): generally assignments between vectors of
> different sizes result in an error.
>
> Additionally I think it would be more intuitive for mathematicians if we
> require vectors to have the same size before assigning them
> (mathematicians? anyone?)
Whether or not it's expected or intuitive is highly subjective. The
question is: will it prevent enough bugs to justify the inconvenience?
IMO the answer is no.
>>> We can't do the same with other objects, and there's no
>>> obvious reason to impose an incompatibility restriction.
>
> resizing a vector comes with a (big) cost. I'm afraid that if the
> resizing is done under the hood, people will be surprised by the
> performance(-penalties) they get.
You have to get the memory for the result of the assignment from
somewhere. The alternative is creating a *new* vector object and
leaving the old one that you would have assigned into alone. That can
only be _more_ expensive.
>>> I can imagine that it becomes quite inconvenient and even
>>> expensive in some cases. For example, constructing unity and
>>> identity matrices might be more painful than neccessary.
>
> I think unity and identity matrices are rather the exception than the
> rule.
Point being?
> For instance, you neither can modify the elements in the unity and
> identity matrices.
That's news to me. I should be able to make a unity matrix and do an
in-place multiplication by a scalar or simply add off-diagonals. I
don't see why not.
> So they are no regular containers like vectors and matrices. Rather
> they are placeholders in an expression(-template).
Ah, that's a different issue. It's probably still advantageous to be
able to default-construct a matrix object and get an identity, just as
you can with a float or an int.
> So I think that for the sake of the identity and unity matrix we can
> justify the drawbacks as described above.
I don't see any significant advantage to imposing a check. The only
good argument I can think of is consistency, but it's not exactly
consistent anyway, because you can't do a compile-time check.
-- Dave Abrahams Boost Consulting www.boost-consulting.com