|
|
Glas :Re: [glas] MTL3 design ? [was MTL project site is up] |
From: David Abrahams (dave_at_[hidden])
Date: 2005-02-03 10:49:55
Theodore Papadopoulo <Theodore.Papadopoulo_at_[hidden]> writes:
> David Abrahams:
>> I won't consider introducing checking in MTL until there is an example
>> of a kind of problem it can prevent that is more serious than the
>> inconvenience the checking introduces. Introducing a checking policy
>> parameter has yet another disadvantage: increased complexity. Don't
>> underestimate this -- it creeps everywhere, including tests and docs.
>> So the problem prevented by checking would have to be more serious
>> than the inconvenience and the complexity.
>
> I just do not understand.... Maybe we are not speaking of the same
> thing ?? What complexity is increased in disallowing assignments
> for vectors of different sizes.
I said that complexity is increased by _introducing a policy
parameter_.
> In any case you have to check that you have enough memory to do the
> copying. The mere difference is that disallowing it you just use an
> assert like line, while to authorize it you need to do the size test
> and add some memory management code (freeing the previous memory,
> allocating the new one).
Correct.
> Actually complexity and cost are increased by allowing assignments
> for vectors of different sizes (unless there is some black magic
> somewhere I do not know of). Less constraints also means more
> testing...
Not really, you need to test the response to violating the constraints
if that's part of the spec.
> So again, where is the inconvenience and the complexity.
Inconvenience is (or might be) there in ruling out default
construction as a possibility. I already covered the complexity
issue.
> Also, how do you believe that allowing assignment of different sizes
> vectors would give any flexibility.
I think that's tautological. You can do something you couldn't do
otherwise. Whether it's useful flexibility is another question
altogether.
> As for how it can prevent a problem, just consider how difficult it
> can be to find a write past the end of an array and how easily it
> could have been caught by one global size check...
Yes, that's a bug. I'm proposing the equivalent of making it not a
bug. Wouldn't it be more convenient if arrays automatically resized
whenever you wrote past the end?
> If a user has a mathematical vector in mind, he also has a size in
> mind... so having the size changed in an assignment behind his back
> is error prone.
Perhaps. How serious are the errors that it prevents?
> The nice thing with asserts is that you are not obliged to pay the
> price for the checks once your code is debugged.
And the downside is that it introduces the possibility of runtime
errors with checking that might even be turned off if you mistakenly
conclude your code is fully tested. So there are trade-offs.
-- Dave Abrahams Boost Consulting www.boost-consulting.com