Re: [boost] [system] system-0.2 request for comments

On 7/22/06, Kim Barrett <kab@irobot.com> wrote:
At 12:10 PM -0400 7/22/06, Beman Dawes wrote:
* Addition of a header boost/identifier.hpp. For years I've used a similar class to provide the type safety and freedom from unwanted conversions that is missing when a simple int is used for an identifier. This is logically separate from the system stuff, but for convenience is included in the system package since error_code.hpp uses it.
This appears to be very similar in intent to the facility provided by boost/strong_typedef.hpp, though there are significant differences in detail.
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. It wouldn't surprise me if Boost has identifier.hpp functionality somewhere, but I'm not aware of anything. --Beman

At 4:10 PM -0400 7/23/06, Beman Dawes wrote:
On 7/22/06, Kim Barrett <kab@irobot.com> 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 detail.
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).
participants (2)
-
Beman Dawes
-
Kim Barrett