[Opaque] Request for interest in Opaque typedefs library emulation

Hi, I have started to play with a class to define opaque typedefs on funcdamental types. It is based on the C++ proposal " Progress toward Opaque Typedefs for C++0X" by Walter E. Brown http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1891.pdf and http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1706.pdf Please take a look on the preceding links to understand the motivation. Boost.Sericalization provide a BOOST_STRONG_TYPEDEF already, but in my opinon the implementation is not complete,as only the order operators are defined (But maybe I'm wrong). Evidently it can not provide everything we can have with a language approach, but IMO this could yet be useful. The library include two class templates (CRTP) to define opaque types: * public_opaque_type<OT,UT> : implicit conversion from OT to UT * private_opaque_type<OT,UT> : no conversion from OT to UT An opaque type (OT) is a new type, different from the underlying type (UT) and other OT. It defines explicit constructor from the UT, and defines all the operators the UT support but this time applied to the OT. To define a new OT with this mixin classes struct serial_number: public_opaque_type<serial_number, unsigned> { BOOST_OPAQUE_PUPLIC_FORWARD_CONSTRUCTORS(serial_number,unsigned); }; struct game_score: private_opaque_type<game_score, unsigned> { BOOST_OPAQUE_PRIVATE_FORWARD_CONSTRUCTORS(game_score,unsigned); }; In addition, defines macros that make this simpler BOOST_OPAQUE_PUBLIC_TYPEDEF(unsigned, serial_number); BOOST_OPAQUE_PRIVATE_TYPEDEF(unsigned, game_score); Next follows the definition of the public_opaque_type template <typename Final, typename T> class public_opaque_type : boost::totally_ordered< Final , boost::integer_arithmetic< Final , boost::bitwise< Final , boost::unit_steppable< Final , boost::totally_ordered< T, Final // public specific conversions , boost::integer_arithmetic< T, Final // public specific conversions , boost::bitwise< T, Final // public specific conversions > > > > > > > { protected: T val_; typedef public_opaque_type opaque_type; public: typedef T underlying_type; explicit public_opaque_type(const T v) : val_(v) {}; public_opaque_type() {}; public_opaque_type(const opaque_type & rhs) : val_(rhs.val_) {} public_opaque_type & operator=(const opaque_type & rhs) { val_ = rhs.val_; return *this; } public_opaque_type & operator=(const T rhs) { val_ = rhs; return *this; } T const& underlying() const { return val_; } T& underlying() { return val_; } operator const T & () const { return val_; } operator T & () { return val_; } #if 0 bool operator==(const opaque_type & rhs) const { return val_ == rhs.val_; } #endif bool operator<(const Final & rhs) const { return val_ < rhs.val_; } Final& operator+=(const Final & rhs) { val_ += rhs.val_; return static_cast<Final&>(*this); } Final& operator-=(const Final & rhs) { val_ -= rhs.val_; return static_cast<Final&>(*this); } ... }; I have started to make some tests and it works well for the moment. Limitations: * As we can not specialize the behaviour of static_cast/dynamic_cast the library sould provide two specific casts opaque_static_cast and opaque_dynamic_static_cast (Not yet implemented). * As operator.() can not be overloaded, it works transparently only for underlying types that don't defines member functions (C++ fundamental types, as int, char, ...). For the others an explicit use of the underlying() member function is needed :( * Others I have not catched yet :( Do you think it is worth continuing? Please, let me know if you see a error on the design. _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

vicente.botet wrote:
The library include two class templates (CRTP) to define opaque types: * public_opaque_type<OT,UT> : implicit conversion from OT to UT * private_opaque_type<OT,UT> : no conversion from OT to UT
Why not name them typedef_public and typedef_private to correlate with the proposed syntax?
To define a new OT with this mixin classes
struct serial_number: public_opaque_type<serial_number, unsigned> { BOOST_OPAQUE_PUPLIC_FORWARD_CONSTRUCTORS(serial_number,unsigned); };
struct game_score: private_opaque_type<game_score, unsigned> { BOOST_OPAQUE_PRIVATE_FORWARD_CONSTRUCTORS(game_score,unsigned); };
Can you imagine any use case in which someone would want to add anything else to such a type? They won't be able to if opaque types ever become part of the standard, will they?
In addition, defines macros that make this simpler
BOOST_OPAQUE_PUBLIC_TYPEDEF(unsigned, serial_number); BOOST_OPAQUE_PRIVATE_TYPEDEF(unsigned, game_score);
BOOST_TYPEDEF_PUBLIC BOOST_TYPEDEF_PRIVATE
Next follows the definition of the public_opaque_type
template <typename Final, typename T> class public_opaque_type : boost::totally_ordered< Final , boost::integer_arithmetic< Final , boost::bitwise< Final , boost::unit_steppable< Final , boost::totally_ordered< T, Final // public specific conversions , boost::integer_arithmetic< T, Final // public specific conversions , boost::bitwise< T, Final // public specific conversions > > > > > > >
That's quite a collection of mixins!
Please, let me know if you see a error on the design.
At first blush, it seems reasonable, but you'll need to test a great variety of use cases to make sure they do only what they should and in many contexts. Here are a few questions that spring to mind: Can you declare such types local to a function? Can you declare such types nested within a UDT? Can you declare such types with others as the underlying type? _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

----- Original Message ----- From: "Stewart, Robert" <Robert.Stewart@sig.com> To: <boost@lists.boost.org> Sent: Friday, May 07, 2010 7:54 PM Subject: Re: [boost] [Opaque] Request for interest in Opaque typedefs library emulation
vicente.botet wrote:
The library include two class templates (CRTP) to define opaque types: * public_opaque_type<OT,UT> : implicit conversion from OT to UT * private_opaque_type<OT,UT> : no conversion from OT to UT
Why not name them typedef_public and typedef_private to correlate with the proposed syntax?
No problem, if this is clearer.
To define a new OT with this mixin classes
struct serial_number: public_opaque_type<serial_number, unsigned> { BOOST_OPAQUE_PUPLIC_FORWARD_CONSTRUCTORS(serial_number,unsigned); };
struct game_score: private_opaque_type<game_score, unsigned> { BOOST_OPAQUE_PRIVATE_FORWARD_CONSTRUCTORS(game_score,unsigned); };
Can you imagine any use case in which someone would want to add anything else to such a type? They won't be able to if opaque types ever become part of the standard, will they?
I have surely misunderstood the text in N1891 §7 "Since only the provider of the opaque-type is in a position to know the desired behavior, we now propose that the function's result in every case be returned as the type originally specified by the function selected by overload resolution, and that any other desired return type be specifically provided by a suitably overloaded version of the function." This let me think that the user could overload the a funtion to change the return type. But it is also thru that the syntax doesn't allows this overloading. So if present they will be in a class inheriting from the opaque typedef, and then the macros will be enough.
In addition, defines macros that make this simpler
BOOST_OPAQUE_PUBLIC_TYPEDEF(unsigned, serial_number); BOOST_OPAQUE_PRIVATE_TYPEDEF(unsigned, game_score);
BOOST_TYPEDEF_PUBLIC BOOST_TYPEDEF_PRIVATE
OK.
Next follows the definition of the public_opaque_type
template <typename Final, typename T> class public_opaque_type : boost::totally_ordered< Final , boost::integer_arithmetic< Final , boost::bitwise< Final , boost::unit_steppable< Final , boost::totally_ordered< T, Final // public specific conversions , boost::integer_arithmetic< T, Final // public specific conversions , boost::bitwise< T, Final // public specific conversions > > > > > > >
That's quite a collection of mixins!
Yes, in order to overload all the operators this was the short way. If the class public_typedef is not needed, I can add all the operator overloadings on the macro directly. Even if this is verbose, it could be a solution to aboid inheritance, if this was a problem.
Please, let me know if you see an error on the design.
At first blush, it seems reasonable, but you'll need to test a great variety of use cases to make sure they do only what they should and in many contexts.
Yes, I know that a lot od cases can broke.
Here are a few questions that spring to mind:
Can you declare such types local to a function? Yes, I think. I will add a test.
Can you declare such types nested within a UDT? Yes, I think. I will add a test.
Can you declare such types with others as the underlying type? Yes, and as defined in N1891, only the implicit conversion to the UT is ensured for public typedefs.
BOOST_OPAQUE_PUBLIC_TYPEDEF(A, B); BOOST_OPAQUE_PUBLIC_TYPEDEF(B, C); B is convertible to A, C is convertible to B, but C is not convertible to A. Thanks Rob for your comments, I will comeback after BoostCon with the suggested modifications and tests. Vicente

On Thu, May 6, 2010 at 2:07 PM, vicente.botet <vicente.botet@wanadoo.fr>wrote:
Hi,
I have started to play with a class to define opaque typedefs on funcdamental types. It is based on the C++ proposal " Progress toward Opaque Typedefs for C++0X" by Walter E. Brown http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1891.pdf and http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1706.pdf
Please take a look on the preceding links to understand the motivation.
Boost.Sericalization provide a BOOST_STRONG_TYPEDEF already, but in my opinon the implementation is not complete,as only the order operators are defined (But maybe I'm wrong).
Evidently it can not provide everything we can have with a language approach, but IMO this could yet be useful.
The library include two class templates (CRTP) to define opaque types: * public_opaque_type<OT,UT> : implicit conversion from OT to UT * private_opaque_type<OT,UT> : no conversion from OT to UT
An opaque type (OT) is a new type, different from the underlying type (UT) and other OT. It defines explicit constructor from the UT, and defines all the operators the UT support but this time applied to the OT.
To define a new OT with this mixin classes
struct serial_number: public_opaque_type<serial_number, unsigned> { BOOST_OPAQUE_PUPLIC_FORWARD_CONSTRUCTORS(serial_number,unsigned); };
struct game_score: private_opaque_type<game_score, unsigned> { BOOST_OPAQUE_PRIVATE_FORWARD_CONSTRUCTORS(game_score,unsigned); };
In addition, defines macros that make this simpler
BOOST_OPAQUE_PUBLIC_TYPEDEF(unsigned, serial_number); BOOST_OPAQUE_PRIVATE_TYPEDEF(unsigned, game_score);
Next follows the definition of the public_opaque_type
template <typename Final, typename T> class public_opaque_type : boost::totally_ordered< Final , boost::integer_arithmetic< Final , boost::bitwise< Final , boost::unit_steppable< Final , boost::totally_ordered< T, Final // public specific conversions , boost::integer_arithmetic< T, Final // public specific conversions , boost::bitwise< T, Final // public specific conversions > > > > > > > { protected: T val_; typedef public_opaque_type opaque_type; public: typedef T underlying_type; explicit public_opaque_type(const T v) : val_(v) {}; public_opaque_type() {}; public_opaque_type(const opaque_type & rhs) : val_(rhs.val_) {} public_opaque_type & operator=(const opaque_type & rhs) { val_ = rhs.val_; return *this; } public_opaque_type & operator=(const T rhs) { val_ = rhs; return *this; } T const& underlying() const { return val_; } T& underlying() { return val_; } operator const T & () const { return val_; } operator T & () { return val_; } #if 0 bool operator==(const opaque_type & rhs) const { return val_ == rhs.val_; } #endif bool operator<(const Final & rhs) const { return val_ < rhs.val_; } Final& operator+=(const Final & rhs) { val_ += rhs.val_; return static_cast<Final&>(*this); } Final& operator-=(const Final & rhs) { val_ -= rhs.val_; return static_cast<Final&>(*this); } ... };
I have started to make some tests and it works well for the moment.
Limitations:
* As we can not specialize the behaviour of static_cast/dynamic_cast the library sould provide two specific casts opaque_static_cast and opaque_dynamic_static_cast (Not yet implemented). * As operator.() can not be overloaded, it works transparently only for underlying types that don't defines member functions (C++ fundamental types, as int, char, ...). For the others an explicit use of the underlying() member function is needed :( * Others I have not catched yet :(
Do you think it is worth continuing?
Please, let me know if you see a error on the design.
Hi Vicente, I am testing Boost.Opaque. I am using Boost 1.47 + Boost.Conversion + Boost.Opaque ( both from the sandbox ). GCC 4.4 on Linux When I include #include <boost/opaque.hpp> ... I get compilation errors ... boost/opaque/meta_mixin/using_explicit_conversion_to_ut_hierarchy.hpp:81: error: ‘boost::dummy’ has not been declared boost/opaque/meta_mixin/using_explicit_conversion_to_ut_hierarchy.hpp:81: error: expected ‘,’ or ‘...’ before ‘<’ token I miss something? Thanks and regards, Fernando.

Fernando Pelliccioni wrote:
On Thu, May 6, 2010 at 2:07 PM, vicente.botet <vicente.botet@wanadoo.fr>wrote:
Hi,
I have started to play with a class to define opaque typedefs on funcdamental types. It is based on the C++ proposal " Progress toward Opaque Typedefs for C++0X" by Walter E. Brown http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1891.pdf and http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1706.pdf
Please take a look on the preceding links to understand the motivation.
Boost.Sericalization provide a BOOST_STRONG_TYPEDEF already, but in my opinon the implementation is not complete,as only the order operators are defined (But maybe I'm wrong).
Evidently it can not provide everything we can have with a language approach, but IMO this could yet be useful.
The library include two class templates (CRTP) to define opaque types: * public_opaque_type<OT,UT> : implicit conversion from OT to UT * private_opaque_type<OT,UT> : no conversion from OT to UT
An opaque type (OT) is a new type, different from the underlying type (UT) and other OT. It defines explicit constructor from the UT, and defines all the operators the UT support but this time applied to the OT.
To define a new OT with this mixin classes
struct serial_number: public_opaque_type<serial_number, unsigned> { BOOST_OPAQUE_PUPLIC_FORWARD_CONSTRUCTORS(serial_number,unsigned); };
struct game_score: private_opaque_type<game_score, unsigned> { BOOST_OPAQUE_PRIVATE_FORWARD_CONSTRUCTORS(game_score,unsigned); };
In addition, defines macros that make this simpler
BOOST_OPAQUE_PUBLIC_TYPEDEF(unsigned, serial_number); BOOST_OPAQUE_PRIVATE_TYPEDEF(unsigned, game_score);
Next follows the definition of the public_opaque_type
template <typename Final, typename T> class public_opaque_type : boost::totally_ordered< Final , boost::integer_arithmetic< Final , boost::bitwise< Final , boost::unit_steppable< Final , boost::totally_ordered< T, Final // public specific conversions , boost::integer_arithmetic< T, Final // public specific conversions , boost::bitwise< T, Final // public specific conversions > > > > > > > { protected: T val_; typedef public_opaque_type opaque_type; public: typedef T underlying_type; explicit public_opaque_type(const T v) : val_(v) {}; public_opaque_type() {}; public_opaque_type(const opaque_type & rhs) : val_(rhs.val_) {} public_opaque_type & operator=(const opaque_type & rhs) { val_ = rhs.val_; return *this; } public_opaque_type & operator=(const T rhs) { val_ = rhs; return *this; } T const& underlying() const { return val_; } T& underlying() { return val_; } operator const T & () const { return val_; } operator T & () { return val_; } #if 0 bool operator==(const opaque_type & rhs) const { return val_ == rhs.val_; } #endif bool operator<(const Final & rhs) const { return val_ < rhs.val_; } Final& operator+=(const Final & rhs) { val_ += rhs.val_; return static_cast<Final&>(*this); } Final& operator-=(const Final & rhs) { val_ -= rhs.val_; return static_cast<Final&>(*this); } ... };
I have started to make some tests and it works well for the moment.
Limitations:
* As we can not specialize the behaviour of static_cast/dynamic_cast the library sould provide two specific casts opaque_static_cast and opaque_dynamic_static_cast (Not yet implemented). * As operator.() can not be overloaded, it works transparently only for underlying types that don't defines member functions (C++ fundamental types, as int, char, ...). For the others an explicit use of the underlying() member function is needed :( * Others I have not catched yet :(
Do you think it is worth continuing?
Please, let me know if you see a error on the design.
Hi Vicente,
I am testing Boost.Opaque. I am using Boost 1.47 + Boost.Conversion + Boost.Opaque ( both from the sandbox ). GCC 4.4 on Linux
When I include
#include <boost/opaque.hpp>
... I get compilation errors ...
boost/opaque/meta_mixin/using_explicit_conversion_to_ut_hierarchy.hpp:81: error: ‘boost::dummy’ has not been declared boost/opaque/meta_mixin/using_explicit_conversion_to_ut_hierarchy.hpp:81: error: expected ‘,’ or ‘...’ before ‘<’ token
I miss something?
Hi, I guess that my last changes on Boost.Conversions are the cause. I forgot to adapt Boost.Opaque to the new interface. I will do it today or tomorrow. Thanks for catching it, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Opaque-Request-for-interest-in-Opaque-typ... Sent from the Boost - Dev mailing list archive at Nabble.com.

Vicente Botet wrote:
Fernando Pelliccioni wrote:
On Thu, May 6, 2010 at 2:07 PM, vicente.botet <vicente.botet@wanadoo.fr>wrote:
Hi Vicente,
When I include
#include <boost/opaque.hpp>
... I get compilation errors ...
I miss something?
Hi,
I guess that my last changes on Boost.Conversions are the cause. I forgot to adapt Boost.Opaque to the new interface. I will do it today or tomorrow.
Thanks for catching it, Vicente
Hi again, I have removed the dependency on Boost.Conversion temporarily. svn ci . -m "Opaque: Avoid dependency on Boost.Conversion" Sending test/Jamfile.v2 Sending test/new_class/using_plus_assign_pass.cpp Transmitting file data .. Committed revision 73258. -- View this message in context: http://boost.2283326.n4.nabble.com/Opaque-Request-for-interest-in-Opaque-typ... Sent from the Boost - Dev mailing list archive at Nabble.com.

On Wed, Jul 20, 2011 at 1:36 PM, Vicente Botet <vicente.botet@wanadoo.fr>wrote:
Vicente Botet wrote:
Fernando Pelliccioni wrote:
On Thu, May 6, 2010 at 2:07 PM, vicente.botet <vicente.botet@wanadoo.fr>wrote:
Hi Vicente,
When I include
#include <boost/opaque.hpp>
... I get compilation errors ...
I miss something?
Hi,
I guess that my last changes on Boost.Conversions are the cause. I forgot to adapt Boost.Opaque to the new interface. I will do it today
or
tomorrow.
Thanks for catching it, Vicente
Hi again,
I have removed the dependency on Boost.Conversion temporarily.
svn ci . -m "Opaque: Avoid dependency on Boost.Conversion" Sending test/Jamfile.v2 Sending test/new_class/using_plus_assign_pass.cpp Transmitting file data .. Committed revision 73258.
Hi Vicente, Can Boost.Opaque supports something like this ... ? void test_iostream_concept() { typedef ?????????? any_type; //define any_type using boost.opaque with meta-mixins typedef std::vector<any_type> ostr_vec; ostr_vec vec; io::stream<sink_x> writer1; //boost iostreams std::ofstream f1("test.txt"); vec.push_back( any_type(writer1) ); vec.push_back( any_type(std::cout) ); vec.push_back( any_type(f1) ); ostr_vec::const_iterator it = vec.begin(); ostr_vec::const_iterator end = vec.end(); for ( ; it != end; ++it ) { //(*it) << "hello " << "world!"; //(1) compile-time error. any_type do not support operator<< } } Thanks and regards, Fernando.

Fernando Pelliccioni wrote:
On Wed, Jul 20, 2011 at 1:36 PM, Vicente Botet <vicente.botet@wanadoo.fr>wrote:
Hi Vicente,
Can Boost.Opaque supports something like this ... ?
void test_iostream_concept() { typedef ?????????? any_type; //define any_type using boost.opaque with meta-mixins
typedef std::vector<any_type> ostr_vec; ostr_vec vec;
io::stream<sink_x> writer1; //boost iostreams std::ofstream f1("test.txt");
vec.push_back( any_type(writer1) ); vec.push_back( any_type(std::cout) ); vec.push_back( any_type(f1) );
ostr_vec::const_iterator it = vec.begin(); ostr_vec::const_iterator end = vec.end();
for ( ; it != end; ++it ) { //(*it) << "hello " << "world!"; //(1) compile-time error. any_type do not support operator<< } }
Hi, Boost.Opaque is intended to define types that different from others. What I think you are looking for is provided by Boost.TypeErasure (from Steave Watanave). I pretend to adapt Boost.Opaque to the design of Boost.TypeErasure (as I missed some features (, as multiple overloadings) that can not be provided with the current design). Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Opaque-Request-for-interest-in-Opaque-typ... Sent from the Boost - Dev mailing list archive at Nabble.com.

Hi Vicente, On Wed, Jul 20, 2011 at 12:56 PM, Vicente Botet <vicente.botet@wanadoo.fr>wrote:
Fernando Pelliccioni wrote:
On Thu, May 6, 2010 at 2:07 PM, vicente.botet <vicente.botet@wanadoo.fr>wrote:
Hi,
I have started to play with a class to define opaque typedefs on funcdamental types. It is based on the C++ proposal " Progress toward Opaque Typedefs for C++0X" by Walter E. Brown http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1891.pdf and http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1706.pdf
Please take a look on the preceding links to understand the motivation.
Boost.Sericalization provide a BOOST_STRONG_TYPEDEF already, but in my opinon the implementation is not complete,as only the order operators
are
defined (But maybe I'm wrong).
Evidently it can not provide everything we can have with a language approach, but IMO this could yet be useful.
The library include two class templates (CRTP) to define opaque types: * public_opaque_type<OT,UT> : implicit conversion from OT to UT * private_opaque_type<OT,UT> : no conversion from OT to UT
An opaque type (OT) is a new type, different from the underlying type (UT) and other OT. It defines explicit constructor from the UT, and defines all the operators the UT support but this time applied to the OT.
To define a new OT with this mixin classes
struct serial_number: public_opaque_type<serial_number, unsigned> { BOOST_OPAQUE_PUPLIC_FORWARD_CONSTRUCTORS(serial_number,unsigned); };
struct game_score: private_opaque_type<game_score, unsigned> { BOOST_OPAQUE_PRIVATE_FORWARD_CONSTRUCTORS(game_score,unsigned); };
In addition, defines macros that make this simpler
BOOST_OPAQUE_PUBLIC_TYPEDEF(unsigned, serial_number); BOOST_OPAQUE_PRIVATE_TYPEDEF(unsigned, game_score);
Next follows the definition of the public_opaque_type
template <typename Final, typename T> class public_opaque_type : boost::totally_ordered< Final , boost::integer_arithmetic< Final , boost::bitwise< Final , boost::unit_steppable< Final , boost::totally_ordered< T, Final // public specific conversions , boost::integer_arithmetic< T, Final // public specific conversions , boost::bitwise< T, Final // public specific conversions > > > > > > > { protected: T val_; typedef public_opaque_type opaque_type; public: typedef T underlying_type; explicit public_opaque_type(const T v) : val_(v) {}; public_opaque_type() {}; public_opaque_type(const opaque_type & rhs) : val_(rhs.val_) {} public_opaque_type & operator=(const opaque_type & rhs) { val_ = rhs.val_; return *this; } public_opaque_type & operator=(const T rhs) { val_ = rhs; return *this; } T const& underlying() const { return val_; } T& underlying() { return val_; } operator const T & () const { return val_; } operator T & () { return val_; } #if 0 bool operator==(const opaque_type & rhs) const { return val_ == rhs.val_; } #endif bool operator<(const Final & rhs) const { return val_ < rhs.val_; } Final& operator+=(const Final & rhs) { val_ += rhs.val_; return static_cast<Final&>(*this); } Final& operator-=(const Final & rhs) { val_ -= rhs.val_; return static_cast<Final&>(*this); } ... };
I have started to make some tests and it works well for the moment.
Limitations:
* As we can not specialize the behaviour of static_cast/dynamic_cast the library sould provide two specific casts opaque_static_cast and opaque_dynamic_static_cast (Not yet implemented). * As operator.() can not be overloaded, it works transparently only for underlying types that don't defines member functions (C++ fundamental types, as int, char, ...). For the others an explicit use of the underlying() member function is needed :( * Others I have not catched yet :(
Do you think it is worth continuing?
Please, let me know if you see a error on the design.
Hi Vicente,
I am testing Boost.Opaque. I am using Boost 1.47 + Boost.Conversion + Boost.Opaque ( both from the sandbox ). GCC 4.4 on Linux
When I include
#include <boost/opaque.hpp>
... I get compilation errors ...
boost/opaque/meta_mixin/using_explicit_conversion_to_ut_hierarchy.hpp:81: error: ‘boost::dummy’ has not been declared boost/opaque/meta_mixin/using_explicit_conversion_to_ut_hierarchy.hpp:81: error: expected ‘,’ or ‘...’ before ‘<’ token
I miss something?
Hi,
I guess that my last changes on Boost.Conversions are the cause. I forgot to adapt Boost.Opaque to the new interface. I will do it today or tomorrow.
Don't worry, take your time.
Thanks for catching it,
not at all Regards, Fernando.
participants (4)
-
Fernando Pelliccioni
-
Stewart, Robert
-
Vicente Botet
-
vicente.botet