|
|
Glas :Re: [glas] MTL3 design ? [was MTL project site is up] |
From: David Abrahams (dave_at_[hidden])
Date: 2005-02-03 08:48:51
Karl Meerbergen <Karl.Meerbergen_at_[hidden]> writes:
>>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.
Real-life cases count for a lot. My opposition to size checking is
based only on intuition.
So, what exactly did you encounter? Was it a bug that could have been
prevented by disallowing assignment of vectors of different sizes at
runtime? What were the details?
> The less is allowed the easier unwanted effects become clear.
True.
> The most important question is do we want vectors to be resized. I
> do not think so.
I don't consider that to be quite the same question as "should
assignment between different sizes be allowed?"
Even what we normally call an "immutable string" can be reassigned,
but it can't be explicitly resized (or otherwise modified).
>>>>> 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
Who mentioned temporaries? And where's the rest of your sentence?
-- Dave Abrahams Boost Consulting www.boost-consulting.com