|
|
Glas :Re: [glas] MTL3 design ? [was MTL project site is up] |
From: Karl Meerbergen (Karl.Meerbergen_at_[hidden])
Date: 2005-02-03 02:38:58
David Abrahams wrote:
>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.
>
>
I think the answer is yes. I have encoutered it recently at FFT. The
less is allowed the easier unwanted effects become clear.
The most important question is do we want vectors to be resized. I do
not think so.
>
>
>>>>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.
>
In many situation you do not need a tempory vector to be created. The right
>
>
>
>>>>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.
>
>
>