Re: Type safety, C++ and code generation

[Maciej Sobczak <no.spam@no.spam.com>]

Georg Bauhaus wrote:

>>type ranged_type<int, 0, 250> Speed;
>>Speed s1, s2, s3; // with some values
>>s1 = s2 + s3; // OK
>>s1 = s2 * s3; // not OK
>>
>>The addition is fine, but the multiplication should not be provided,
>>because speed multiplied by speed is not a speed. Can you extend your
>>class so that the compiler will refuse to compile the second operation
>>above?
>>(Ada, anyone? :) )
> 
> 
> Just so it is visible:
> 
> 
> procedure useop is
> 
>    s1, s2, s3: SPEED;  -- with some values
> 
> begin
>    s3 := s1 * s2;
> end useop;
> 
>      8.    s3 := s1 * s2;
>                     |
>         >>> cannot call abstract subprogram "*"
> 
> where
> 
> package Op is
> 
>    type SPEED is range 0 .. 250;
> 
>    function "*"(a, b: SPEED) return SPEED is abstract;
> 
> end Op;

I like it, although there is some potential problem with this approach. 
It uses the "negative logic" - in other words, specifies what is 
forbidden, not what is allowed - so it's more prone to errors than the 
"positive logic", where you specify what *is* supported instead. In the 
"positive logic" approach you can start with the default setting (no 
operations) and the compiler will point you to each new operation usage 
in your code - then, you can either consciously extend the type 
definition to cover the new use case or reject it if it was a bug. It's 
much more cumbersome with the "negative logic", where the default 
setting provides no protection at all.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/