Re: Type safety, C++ and code generation
- From: Maciej Sobczak <no.spam@xxxxxxxxxxx>
- Date: Thu, 27 Apr 2006 17:16:45 +0200
REH wrote:
http://www.msobczak.com/prog/typegen/
You maybe interested in a C++ class that I wrote.
Been there, done that:
http://www.msobczak.com/prog/downloads.html
(see safetypes.tar.gz and range.tar.gz)
I don't see where you've "done that."
The template class that implements range checking?
I have dropped this idea because I think that the external code
generator is much more flexible and more powerful with regard to the
type safety that can be gained. Range checking is just one little part
of what is needed. Template classes are fine if you can afford limiting
yourself only to this little part, but that's not usually the case.
I never said it was the end-all-be-all, just thought you may be
interested. I don't know what you think templates are limiting you to.
It's not about templates themselves, but rather about the whole approach.
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;
Above, R1 and R2 are *equal* to the compiler, but R3 is distinct from the other two. This is or can be problematic in those contexts where you would rather expect them all to be different from each other - especially when you think in terms of different *domains*, no matter what is their range of values.
Another problem is that the range, as a set of values, is not the only thing that constitues a type - you also need to define the set of legal operations. The problem is that I usually want them to be different in each type.
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?
(Ada, anyone? :) )
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?
(Ada, anyone? :) )
And so on - all this *can* be done with templates, but at some point this approach just saturates and the code becomes a nightmare. Not mentioning the error messages that you get from the compiler (and the whole purpose of this is to actually get *useful* error messages, right?). And not mentioning the compilation time.
These are exactly the factors that limit the practical useability of the template approach and that's why I claim that external code generator can be much more powerful.
--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
.
- Follow-Ups:
- Re: Type safety, C++ and code generation
- From: Martin Krischik
- Re: Type safety, C++ and code generation
- From: adaworks
- Re: Type safety, C++ and code generation
- From: REH
- Re: Type safety, C++ and code generation
- From: Georg Bauhaus
- Re: Type safety, C++ and code generation
- 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
- Type safety, C++ and code generation
- Prev by Date: Re: Type safety, C++ and code generation
- Next by Date: Re: procedural vs object oriented
- Previous by thread: Re: Type safety, C++ and code generation
- Next by thread: Re: Type safety, C++ and code generation
- Index(es):
Relevant Pages
|