Boost logo

Boost :

Subject: Re: [boost] Interest in specialized types
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-08-22 15:22:35

Pierre Morcello wrote:
> Henning Basold wrote :
>> Robert Ramey talked about wrapping some POD to increase type
>> safety. Some time ago I used something similar to ensure
>> that misuse of values can be found by the compiler.
>> So I think that is something that can be generalized. The
>> concept is to wrap a type into a class and restrict the
>> interface. This ensures that values from one context (e.g.
>> an id) can't be used in another context (e.g. adding of
>> number or as an id for other objects).
> [...]
>> Do you think this might be a useful utility? Or is there
>> something similar already available? [...]
> Personnaly, I simply use a strongtypedef macro. A good news is that
> there is already one done in serialization : strong_typedef.hpp
> (maybe this one could have gone into boost.utility?).
> I think you have got something to dig, even if I am not convinced
> that I would use your interface in a real project over the already
> existing strong_typedef. Could you give some real world cunny
> examples of use?

I see this proposal as quite different from strong_typedef (and by
implication opaque which I think is a better implementation of
strong_typedef). When I say strong_typedef here I'm referring

strong_typedef is just a way to assign a type to an integer or
other POD type. It inherits all the operators and is free convertible
to the underlying type. It's useful for template meta-programming
where one wants to dispatch to code depending on the the type.
In effect, it creates a compile time pair <specialized_type, POD>
which acts just like the POD but is distinguishable. One use case
for this is the serialization library which permits one to have different
code to handle special types which are in fact integers and permit
them to be trapped and handled specially without accidently invoking
the serialization code for the original POD through the whole program.

This proposal is quite different. Rather than inheriting all the behavior
of the underlying POD, it's purpose is to restrict it - thereby trapping
non-sensical operations at compile time. I do see the value in generalizing
this - bascally to avoid rookie mistakes like leaving out the assignment
operartor (which C++ "helpfully" sticks in for me). So I think this idea
DOES have merit.

I looked a little at your implementation and I think it's very, very cool.

This is going to start a whole new thread. Here are the things that
come to my mind.

a) The implementation isn't really enough for me to visualize how easy
and useful it would be to use. I realize that making a document with
tutorial and examples is a bigger effort, but I for one would encourage
you to invest this effort.

b) When I see a concept "Additive" I'm thinking uh-oh, this is going
to spin a whole lot of new stuff. Here is what goes on in my brain.

Additive - hmmm why not multiplicative
Additive/multiplicative - why not step back to

set element - no operations except equality
group element - additive operators + null element
different types of groups?
field element - additive + multiplacative + ...

Which to me is a facinating direction. I believe that there have been
proposals for C++ libraries to manage these kind of types. And
of course there is the unit's library which touchs this area.

Sooooooooo - maybe you want to drop "additive" or maybe not.

Anyway, I would encourage you to spend more effort in this. I
was using strong_typedef and it was fine for my purposes. But
I moved to the "restricted" typedef to elminate warnings and
trap bugs. So there is definitely a use for such a thing.

I see this idea as one of those few which can be a library
small enough to actually do, be easy and useful to use. There
aren't many opportunities like this these days.

Good luck with this.

Robert Ramey

Boost list run by bdawes at, gregod at, cpdaniel at, john at