Re: Type safety, C++ and code generation
- From: Maciej Sobczak <no.spam@xxxxxxxxxxx>
- Date: Fri, 28 Apr 2006 08:17:00 +0200
REH wrote:
I don't see where you've "done that."
The template class that implements range checking?
NO, a class that uses template to ELIMINATE unnecessary checks.
As I've said, I dropped this idea (using templates and metaprogramming techniques as a basis for building safer type system - this is what I mean by "done that"), because for me it doesn't scale.
What about making different types really distinct?
typedef ranged_type<int, 0, 100> R1;
typedef ranged_type<int, 0, 100> R2;
typedef ranged_type<int, 0, 101> R3;
My code uses this technique if you want truely unqiue types:
class R1_unique{};
class R2_unique{};
typedef ranged_type<int, 0, 100, R1_unique> R1;
typedef ranged_type<int, 0, 100, R2_unique> R2;
Of course, but this requires increased involvement of the user. Above, it is necessary to define two things to achieve what is conceptually only one goal. This is one of the limiting factors of this approach - it quickly "saturates" and becomes a maintenance nighmare for both the library writer and its users.
I akcnowledge that either the language has to inherently support this kind of stuff (like Ada does), or it's better to step *outside* of the language and use metamodels and some generation techniques.
Consider this:
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?
Yes, you derive from the class and put the multiplication operator in
the private scope.
Which is the "negative logic" (see my answer to Georg Bauhaus) and it also creates additional entity (the derived class) for reasons that have nothing to do with the original design. What about the base class, which still supports the unwanted operations?
What about this:
Velocity v;
Duration t;
Distance d = v * t; // OK
Distance d = v + t; // not OK
Now, the operation involves three types. Derivation and messing with private specifier is not a very scalable solution.
Another problem is variation of the behaviour in the out-of-range
condition. What should happen then? Throw an exception? That's only one
of at least four different options I can imagine, and also not the one I
would choose most of the time. Does your class allow variations here?
Yes, the template takes a traits class. If allow modification of
various behaviors, such as what should be done with an out-of-range
value, an overflow condition, a divide-by-zero, etc.
Fine (and I've "done that").
And now, with all this traits-and-derivation-and-tagging-and-what-not, is it easy for the user to understand the typical compiler error message?
--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
.
- References:
- Type safety, C++ and code generation
- From: Maciej Sobczak
- Re: Type safety, C++ and code generation
- From: REH
- Re: Type safety, C++ and code generation
- From: Maciej Sobczak
- Re: Type safety, C++ and code generation
- From: REH
- Re: Type safety, C++ and code generation
- From: Maciej Sobczak
- Re: Type safety, C++ and code generation
- From: REH
- Type safety, C++ and code generation
- Prev by Date: Re: Type safety, C++ and code generation
- Next by Date: Re: Type safety, C++ and code generation
- Previous by thread: Re: Type safety, C++ and code generation
- Next by thread: Re: Type safety, C++ and code generation
- Index(es):
Relevant Pages
|
