From: Kim Barrett (kab_at_[hidden])
Date: 2006-07-24 21:29:35
At 4:10 PM -0400 7/23/06, Beman Dawes wrote:
>On 7/22/06, Kim Barrett <kab_at_[hidden]> wrote:
>> At 12:10 PM -0400 7/22/06, Beman Dawes wrote:
> > >* Addition of a header boost/identifier.hpp.
>> This appears to be very similar in intent to the facility provided by
>> boost/strong_typedef.hpp, though there are significant differences in
>The intents of identifier.hpp and strong_typedef differ. A strong
>typedef retains all operations on the underlying type in the new type.
>An identifier only provides a very limited set of operations on the
>new type. That is so an operation like multiplication of an
>identifier, which is almost certainly an error, is not permitted and
>will be detected by the complier.
I did say *similar* :)
Note that for strong_typedef, applying arithmetic operations from an
integral base type (for example) produces a result which is the integral
promotion type from the base type and the other argument type(s), so it
isn't obvious to me how useful that particular feature of strong_typedef
actually is. I also note that all of the uses of strong_typedef (within
boost) I've looked at seem to only use comparisons, and not other operations
from the underlying type.
It also seems that strong_typedef and your identifier might be specific
points on a spectrum. Ah, reading ahead in this thread, I see that David
Bergman has the same notion.
Note that none of my comments should be taken as criticism of the basic
notion here. I'd just prefer to have one round wheel rather than two
elliptical ones. And as my comment above regarding the actual utility
of picking up the full set of base-type operations indicates, I think
it is entirely possible that your identifier (or whatever it ends up
being called) might be the round wheel I'm looking for, and I would
likely use it instead of strong_typedef.
And yes, it should be a separate facility, rather than buried deep inside
the system library (or the serialization library, for that matter).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk