Re: [boost] Interest in specialized types

Subject: Re: [boost] Interest in specialized types
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-08-22 13:22:16

----- 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