|
|
Glas :Re: [glas] MTL3 design ? [was MTL project site is up] |
From: David Abrahams (dave_at_[hidden])
Date: 2005-02-03 10:56:59
Karl Meerbergen <Karl.Meerbergen_at_[hidden]> writes:
> On Thursday 03 February 2005 14:48, David Abrahams wrote:
>> 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.
>
> I do not recall the details. If I recall a matrix was resized,
> because the right-hand side had a wrong size. This created some
> problems elsewhere when the vector was used after the copy.
>
> There are different ways to solve such problems:
> 1) assert after the assignment to check whether the size has changed
? You should always detect and report errors at the earliest possible
moment. That means immediately upon entering the assignment.
> 2) have an assignment function that does not allow resizing.
>
> Which one do we want, or do we allow both?
>
> I agree with Dave that this is not part of the Vector concept, it is merely a
> behaviour of the assignment. Is this what you meant, Dave?
No, I meant that it's a behavior of some specific types that satisfy
the Vector concept. Nobody has made a clear case that convinces me
the library should supply a vector type with runtime resizing
restrictions.
-- Dave Abrahams Boost Consulting www.boost-consulting.com