|
Boost : |
Subject: Re: [boost] Interest in specialized types
From: Henning Basold (h.basold_at_[hidden])
Date: 2010-08-22 14:37:02
Am 22.08.2010 19:22, schrieb vicente.botet:
> ----- Original Message -----
> From: "Henning Basold"<h.basold_at_[hidden]>
> To:<boost_at_[hidden]>
> Sent: Sunday, August 22, 2010 5:49 PM
> Subject: [boost] Interest in specialized types
>
>
>> Hello,
>>
>> in http://permalink.gmane.org/gmane.comp.lib.boost.devel/207794 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).
>>
>> Attached is a very simple implementation where the needed concepts can
>> be specified as parameter. To distinguish for example between different
>> id types also a tag type can be specified.
>>
>> Do you think this might be a useful utility? Or is there something
>> similar already available? I've searched the vault but did not find
>> anything.
> Hi,
>
> I'm currently working on Boost.Opaque http://svn.boost.org/svn/boost/sandbox/opaque/ (Not yet on the Vault) which tries to implement strong typedefs for fundamental types. It is based on "Progress toward Opaque Typedefs for C++0X" http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1891.pdf which was not accepted for inclusion on C++0x.
>
> // Cartesian 3D coordinate types
> BOOST_OPAQUE_PUBLIC_TYPEDEF(double, X);
> BOOST_OPAQUE_PUBLIC_TYPEDEF(double, Y);
> BOOST_OPAQUE_PUBLIC_TYPEDEF(double, Z);
>
> // polar 3D coordinate types
> BOOST_OPAQUE_PUBLIC_TYPEDEF(double, Rho);
> BOOST_OPAQUE_PUBLIC_TYPEDEF(double, Theta);
> BOOST_OPAQUE_PUBLIC_TYPEDEF(double, Phi);
>
> class PhysicsVector {
> public:
> PhysicsVector(X, Y, Z);
> PhysicsVector(Rho, Theta, Phi);
> ...
> }; // PhysicsVector
>
> The approach I have taken doesn't allows, as yours, to restrict the interface but just to allow or not the implicit conversion between the opaque/strong-typed type and the underlying type.
>
> I recognize that the ability to restrict the interface is more general, but I'll need some concrete use cases for which restricting the interface is absolutlely needed.
>
> Best,
> Vicente
>
> _______________________________________________
> Unsubscribe& other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi,
that's very interesting. Especially the interface to test for relation
of types.
The idea to the interface came from the Haskell type system. There one
can define new types and put into a type class. Those type classes
implement some functionality such as ordering. This restricts the usable
interface to the minimum without relying on automatic conversion.
I used the restriction for automatically generated ID objects (see
answer to Pierre's post).
Regards
Henning
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk