[Opaque] Request for interest in Opaque typedefs library emulation

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[Opaque] Request for interest in Opaque typedefs library emulation

Vicente Botet
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/




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Opaque] Request for interest in Opaque typedefs library emulation

Stewart, Robert
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                           [hidden email]
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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Opaque] Request for interest in Opaque typedefs library emulation

Vicente Botet
----- Original Message -----
From: "Stewart, Robert" <[hidden email]>
To: <[hidden email]>
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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Opaque] Request for interest in Opaque typedefs library emulation

fpelliccioni
In reply to this post by Vicente Botet
On Thu, May 6, 2010 at 2:07 PM, vicente.botet <[hidden email]>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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Opaque] Request for interest in Opaque typedefs library emulation

Vicente Botet
Fernando Pelliccioni wrote
On Thu, May 6, 2010 at 2:07 PM, vicente.botet <[hidden email]>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
Reply | Threaded
Open this post in threaded view
|

Re: [Opaque] Request for interest in Opaque typedefs library emulation

Vicente Botet
Vicente Botet wrote
Fernando Pelliccioni wrote
On Thu, May 6, 2010 at 2:07 PM, vicente.botet <[hidden email]>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.
Reply | Threaded
Open this post in threaded view
|

Re: [Opaque] Request for interest in Opaque typedefs library emulation

fpelliccioni
In reply to this post by Vicente Botet
Hi Vicente,

On Wed, Jul 20, 2011 at 12:56 PM, Vicente Botet <[hidden email]>wrote:

>
> Fernando Pelliccioni wrote:
> >
> > On Thu, May 6, 2010 at 2:07 PM, vicente.botet
> > &lt;[hidden email]&gt;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&lt;OT,UT&gt; : implicit conversion from OT to UT
> >> * private_opaque_type&lt;OT,UT&gt; : 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&lt;serial_number, unsigned&gt;
> >> {
> >>    BOOST_OPAQUE_PUPLIC_FORWARD_CONSTRUCTORS(serial_number,unsigned);
> >> };
> >>
> >> struct game_score: private_opaque_type&lt;game_score, unsigned&gt;
> >> {
> >>    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&lt;Final&amp;&gt;(*this);
> >>        }
> >>        Final& operator-=(const Final & rhs) {
> >>            val_ -= rhs.val_;
> >>            return static_cast&lt;Final&amp;&gt;(*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 &lt;boost/opaque.hpp&gt;
> >
> >
> > ... 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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Opaque] Request for interest in Opaque typedefs library emulation

fpelliccioni
In reply to this post by Vicente Botet
On Wed, Jul 20, 2011 at 1:36 PM, Vicente Botet <[hidden email]>wrote:

>
> Vicente Botet wrote:
> >
> >
> > Fernando Pelliccioni wrote:
> >>
> >> On Thu, May 6, 2010 at 2:07 PM, vicente.botet
> >> &lt;[hidden email]&gt;wrote:
> >>
> >> Hi Vicente,
> >>
> >> When I include
> >>
> >> #include &lt;boost/opaque.hpp&gt;
> >>
> >> ... 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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Opaque] Request for interest in Opaque typedefs library emulation

Vicente Botet
Fernando Pelliccioni wrote
On Wed, Jul 20, 2011 at 1:36 PM, Vicente Botet <[hidden email]>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