|
|
Glas :Re: [glas] Design Principles |
From: Rainer Blome (rainer.blome_at_[hidden])
Date: 2005-02-04 04:23:23
Beforehand, note that I like the idea of variables with dynamic type
(which may refer to similar but different types at different times,
type in this case including the container size). However, in C++ I
expect this to be the (explicitly ordered) exception rather than the rule.
David Abrahams wrote:
> "Rainer Blome" <rainer.blome_at_[hidden]> writes:
>
>> o Avoid implicit conversions, they will hurt you (performance- and
>> safety-wise). Instead, make explicit conversions easy.
>
> Nobody's talking about implicit conversions here AFAIK.
True, I simply stated a related design principle to help start a list.
>> o If it's not required, it should not have to be paid for.
>> Stay "Lean and mean".
>>
>> For example, a program that does not benefit from the convenience
>> of implicit resizing should not have to pay the prices of it
>> (performance hit, less errors caught at compile time, etc.).
>
> I'd be interested in what the "etc." stands for because your other two
> points against implicit resizing are -- with all due respect -- bogus.
"etc. includes at least (can't think of any more right now):
o Space savings
- Code does not need to take care of resizing
- For static sizes, the size is not stored in the container
o Code comprehensibility and maintainability. Currently, I am de facto
working as a maintenance programmer for a system that I did not develop.
If a program is to be used and maintained for more than a few months,
these factors become important (even if no money flows, time still flows).
- No need for the reader to figure
out whether resizing is possible or going to happen or not.
- If the code is to be changed, is the program going to break if the
ability to automatically resize is removed?
> Nobody has demonstrated that implicit resizing causes a performance
> hit as compared to whatever code you'd need to do the same thing
> without having the resizing capability. If I were to write:
>
> x = y;
>
> and that was to cause a size compatibility error, then typically I'd
> need to write
>
> vector newx(y);
>
> instead, which is clearly more expensive.
Why not write 'x.resizing_assign(y)' instead?
> ...
> We're only talking about implicit resizing for types where the size
> can't be part of the type,
I was not aware of that. Many arguments apply to both.
> so there would clearly be exactly the same number of errors caught at compile-time.
In this case, of course.
>> o Make things explicit in general, enable the programmer to express
>> her thoughts.
>
> Good one; I support that idea. But how does forbidding
>
>x = y;
>
> when x and y have different sizes enhance expressivity?
Because the programmer is forced to explicitly state that the
assignment should implicitly resize the target if necessary (see above).
> I'm still interested in [...] arguments for or against implicit resizing.
To me, the size of a numerical vector is part of its conceptual type,
run-time or compile-time.
In this respect, implicit resizing is akin to implicit conversion.
Experience has taught me and others again and again that
implict conversions have and will hurt.
If it were not for the requirement of backwards compatibility,
I bet that C++ would have dropped implicit conversions
(just my unsupported opinion, of course).
However, C++ has introduced cast operators to at least enable the
programmer to explicitly express his intentions when a
conversion is required.
In this case, there is no need to maintain backwards compatibility.
A convenient mechanism for stating that resizing is allowed would
make it easy for the programmer to express his intent.
Rainer
______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193