Formal Review Request: TypeErasure

classic Classic list List threaded Threaded
128 messages Options
1234 ... 7
Reply | Threaded
Open this post in threaded view
|

Formal Review Request: TypeErasure

Steven Watanabe-4
AMDG

I'd like to request a formal review of the
TypeErasure library that I've posted about
several times before here.

The TypeErasure library is a generalization
of boost::any and boost::function.  It
allows easy composition of arbitrary
type erased operators.

As an example of basic usage, we
can simulate Boost.Any:

any<mpl::vector<copy_constructible<>, typeid_<> > > x(10);
int i = any_cast<int>(x); // i == 10

The library is available in the Boost Sandbox at
http://svn.boost.org/svn/boost/sandbox/type_erasure/

You can download archives with pre-built documentation from
http://sourceforge.net/projects/steven-watanabe.u/files/

Online documentation can be found here:
http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/

In Christ,
Steven Watanabe

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

Re: Formal Review Request: TypeErasure

cppljevans
On 05/22/12 15:34, Steven Watanabe wrote:
[snip]
> Online documentation can be found here:
> http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/
[snip]
Looks very interesting.

I've done a somewhat brief review of just the online documentation.
I'll try to do a more complete review later.

Here's my current comments:


* Virtual functions do not *require* dynamic memory:

   The page:

 
http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/doc/html/index.html

   says:

     C++ provides runtime polymorphism through virtual functions. ...
     They require dynamic memory management.

   However, I don't think dynamic memory is required because just
   references to stack locations or pointers pointing to stack
   locations could be used to take advantage of virtual functions.

* 'Operation' term used before defined:

   The page:

 
http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/doc/html/boost_typeerasure/multi.html

   says:

     Operations can have more than one any argument.

   before any definition of 'Operation' occurs.  Only by seeing the:

     addable<>

   argument to the mpl::vector does the term 'Operation' begin to make
   sense, and then the reader has to guess that all the mpl::vector
   arguments are operations, and that all the previous 'operations'
   were unary.

   However, I'm still not sure that's correct. It would help if some
   link to 'Operation' defintion were provided everywhere that the
   term, 'Operation', occurs.

   Maybe, where the term, 'opeation" occurs, there should be a link to:

 
http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/doc/html/boost_typeerasure/predef.html

* 'match' term used before defined:

   The page:

 
http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/doc/html/boost_typeerasure/multi.html

   says:

     The types of the arguments must match or the behavior is
     undefined.

   before any definition of 'match' or 'arguments' occurs.  I'm just
   guessing from the arguments to x and y, that 'arguments' means
   arguments to the any CTOR, but then the CTOR argument to z is an
   expression; hence, I'm guessing that that expression is allowed by
   the addable<> template argument to the mpl::vector arg to the
   any_type.

* public construct/copy/destruct item 1 undefined T:

   The page:

 
http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/doc/html/boost/type_erasure/any.html

   under:

     1. template<typename U> explicit any(const U & data);

   says:

     oncept must not refer to any placeholder besides T.

   However, T is not defined (or the definition is not obvious).

* Mistitled Assign operator description:

   The page:

 
http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/doc/html/boost/type_erasure/any_Concept__T___id2513644.html

   says:

     any public construct/copy/destruct

     1. any& operator=(const any & other);

        Assigns to an any.

   Shouldn't this be retitled something like:

     any public assign operator

     1. any& operator=(const any & other);

        Assigns to an any.

* Misplaced copy CTOR description:

   The page:

 
http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/doc/html/boost/type_erasure/any_Concept__T___id2513644.html

   says:

     any public member functions

       1. template<typename U>  any(U & arg);


   This this is a constructor, not a member function, shouldn't this be
   moved to:

 
http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/doc/html/boost/type_erasure/any.html

   and placed under:

     any public construct/copy/destruct

   Also, all of the other items seem to be CTOR descriptions also;
   hence, shouldn't they be similarly moved?

* Typo "more general" in 'Design Notes.Constructors':

   The page:

 
http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/doc/html/boost_typeerasure/design.html

   says:

     The last kind of constructor "upcasts" from one concept to another
     more general more general concept.

   with the typo of duplicated "more general".



-regards,
Larry



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

Re: Formal Review Request: TypeErasure

Steven Watanabe-4
AMDG

On 05/23/2012 07:31 AM, Larry Evans wrote:

> On 05/22/12 15:34, Steven Watanabe wrote:
> [snip]
>> Online documentation can be found here:
>> http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/
>>
> [snip]
> Looks very interesting.
>
> I've done a somewhat brief review of just the online documentation.
> I'll try to do a more complete review later.
>
> Here's my current comments:
>
>
> * Virtual functions do not *require* dynamic memory:
>
>   The page:
>
>
> http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/doc/html/index.html
>
>
>   says:
>
>     C++ provides runtime polymorphism through virtual functions. ...
>     They require dynamic memory management.
>
>   However, I don't think dynamic memory is required because just
>   references to stack locations or pointers pointing to stack
>   locations could be used to take advantage of virtual functions.
>

In theory, you're correct.  It isn't strictly
necessary.  However, in practice, the cases
where you can avoid new are the exception,
rather than the rule.  I don't want to complicate
the introduction by being overly pedantic.

> * 'Operation' term used before defined:
>
>   The page:
>
>
> http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/doc/html/boost_typeerasure/multi.html
>
>
>   says:
>
>     Operations can have more than one any argument.
>
>   before any definition of 'Operation' occurs.  Only by seeing the:
>

"Operation" is not defined, because it doesn't
have any special formal meaning in my library.
Just take it in it's usual sense of something
that you can do with an any.

>     addable<>
>
>   argument to the mpl::vector does the term 'Operation' begin to make
>   sense, and then the reader has to guess that all the mpl::vector
>   arguments are operations, and that all the previous 'operations'
>   were unary.
>

The very next sentence explicitly contrasts *binary*
addition with increment.  I don't see how I can make
this more clear without a lot of formalism that
would just be off-putting for most people.

>   However, I'm still not sure that's correct. It would help if some
>   link to 'Operation' defintion were provided everywhere that the
>   term, 'Operation', occurs.
>
>   Maybe, where the term, 'opeation" occurs, there should be a link to:
>
>
> http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/doc/html/boost_typeerasure/predef.html
>
>
> * 'match' term used before defined:
>
>   The page:
>
>
> http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/doc/html/boost_typeerasure/multi.html
>
>
>   says:
>
>     The types of the arguments must match or the behavior is
>     undefined.
>
>   before any definition of 'match' or 'arguments' occurs.  I'm just
>   guessing from the arguments to x and y, that 'arguments' means
>   arguments to the any CTOR, but then the CTOR argument to z is an
>   expression; hence, I'm guessing that that expression is allowed by
>   the addable<> template argument to the mpl::vector arg to the
>   any_type.
>

arguments in this case means the arguments of +.
types means the types that the anys hold.
match just means that they're consistent
with what addable<> expects i.e. the same type.
This is the *tutorial*.  I don't want to
put all the technical details here.  If you
come away from this sentence with the idea
that adding an any that stores an int to
an any that stores a string is bad, it's
clear enough for my purposes.

> * public construct/copy/destruct item 1 undefined T:
>
>   The page:
>
>
> http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/doc/html/boost/type_erasure/any.html
>
>
>   under:
>
>     1. template<typename U> explicit any(const U & data);
>
>   says:
>
>     Concept must not refer to any placeholder besides T.
>
>   However, T is not defined (or the definition is not obvious).
>

T is a class template parameter.  I'm
not sure what I can do to make it more
obvious.  Anyway, this comment is no
longer correct.

> * Mistitled Assign operator description:
> * Misplaced copy CTOR description:
>

This is all auto-generated by doxygen/boostbook.
I'll see if I can figure out what went wrong.

>
> * Typo "more general" in 'Design Notes.Constructors':
>
>   The page:
>
>
> http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/doc/html/boost_typeerasure/design.html
>
>
>   says:
>
>     The last kind of constructor "upcasts" from one concept to another
>     more general more general concept.
>
>   with the typo of duplicated "more general".
>

Fixed.

In Christ,
Steven Watanabe


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

Re: Formal Review Request: TypeErasure

lcaminiti
In reply to this post by Steven Watanabe-4
Steven Watanabe-4 wrote
AMDG

I'd like to request a formal review of the
TypeErasure library that I've posted about
several times before here.

The TypeErasure library is a generalization
of boost::any and boost::function.  It
allows easy composition of arbitrary
type erased operators.

As an example of basic usage, we
can simulate Boost.Any:

any<mpl::vector<copy_constructible<>, typeid_<> > > x(10);
int i = any_cast<int>(x); // i == 10

The library is available in the Boost Sandbox at
http://svn.boost.org/svn/boost/sandbox/type_erasure/

You can download archives with pre-built documentation from
http://sourceforge.net/projects/steven-watanabe.u/files/

Online documentation can be found here:
http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/
Hello Steven,

I quickly read the docs (see a couple of minor comments below). I'll compile and play with the examples this weekend.

I'm interested in the library. If you are looking for a Review Manager, I'd like to volunteer if that's OK with you and the Review Wizards.

Minor Comments

1) It'd be nice to have a motivating example up front (something not trivial but not as complex as the range formatter either).

2) Why placeholders _a, _b, ... instead of _1, _2, ...?

3) I found the syntax of concept_interface difficult to understand... for example, Base looks arbitrary. But then it's very nice to be able to c.push_back(10) instead of call(...)

4) Same for overloaded concept_interface where both Base and Enable look arbitrary. (I wonder if macros could generate some of the boiler-plate code for the overload.)

5) There's a FIXME in the Reserved Identifier section.

--Lorenzo
Reply | Threaded
Open this post in threaded view
|

Re: Formal Review Request: TypeErasure

Nathan Ridge

> 2) Why placeholders _a, _b, ... instead of _1, _2, ...?

Because Bind has dibs on _1, _2, ..., and no one wants to write
boost::type_erasure::_1?

Regards,
Nate
     

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

Re: Formal Review Request: TypeErasure

Steven Watanabe-4
In reply to this post by lcaminiti
AMDG

On 05/23/2012 07:12 PM, lcaminiti wrote:
>
> Hello Steven,
>
> I quickly read the docs (see a couple of minor comments below). I'll compile
> and play with the examples this weekend.
>
> I'm interested in the library. If you are looking for a Review Manager, I'd
> like to volunteer if that's OK with you and the Review Wizards.
>

It sounds good to me.  You're a library author,
so I'm sure the Review Wizard will be okay with it.

> Minor Comments
>
> 1) It'd be nice to have a motivating example up front (something not trivial
> but not as complex as the range formatter either).
>

What about something based on any_printable?

typedef any<
  mpl::vector<
    copy_constructible<>,
    typeid_<>,
    ostreamable<> > > any_printable;

I believe that this has come up somewhere.
("Why can't I print boost::any to std::cout?")
Is this about the level of complexity
that you're thinking?

> 2) Why placeholders _a, _b, ... instead of _1, _2, ...?
>

Because they represent named arguments, not
positional arguments.  I used _1, _2, etc.
in an earlier version of the library, and
some people were confused about how they
related to _1, _2 in Boost.Bind and Boost.MPL

> 3) I found the syntax of concept_interface difficult to understand... for
> example, Base looks arbitrary. But then it's very nice to be able to
> c.push_back(10) instead of call(...)
>
> 4) Same for overloaded concept_interface where both Base and Enable look
> arbitrary. (I wonder if macros could generate some of the boiler-plate code
> for the overload.)
>

Did you look at the doxygen/boostbook reference
for concept_interface?  Is that sufficiently clear?

I realize that my descriptions in the examples
are often a bit sparse.  Would something like
this be clearer?  Do you think it's too verbose?

in custom.cpp:
    This works, but we'd really like to call `c.push_back(10)`.
    We can add members to __any by specializing __concept_interface.
    The first argument is `push_back`, since we want to inject a member
    into every __any that uses the `push_back` concept.  The second
argument,
    Base, is used by the library to chain multiple uses of
__concept_interface
    together.  We have to inherit from it publicly.  Other than
    that we can ignore it.  The third argument is the placeholder
    that represents this any.  If someone used `push_back<_c, _b>`,
    we only want to insert a `push_back` member in the container,
    not the value type.  Thus, the third argument is the container
    placeholder.

in overload.cpp:
    This uses SFINAE to detect whether a using declaration is
    needed.  Note that the fourth argument of __concept_interface
    is a dummy parameter which is always void and is
    intended to be used for SFINAE.

> 5) There's a FIXME in the Reserved Identifier section.
>

Yeah.  I haven't come up with any scheme that
covers all the identifiers I want to be able to
use without being too broad.  I suppose I can
always ignore the issue until problems surface
like everyone else.

In Christ,
Steven Watanabe

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

Re: Formal Review Request: TypeErasure

Simonson, Lucanus J
In reply to this post by Steven Watanabe-4
Steven Watanabe wrote:

> I'd like to request a formal review of the TypeErasure library that I've posted about several times before here.
>The TypeErasure library is a generalization of boost::any and boost::function.  It allows easy composition of arbitrary type erased operators.

It seems the library is a little more than that.  Have you considered naming it Boost.DuckTyping?  I think TypeErasure doesn't really capture the full scope of what you've done.

A much longer example where you use the library to implement something with some explanation of why you would want to use the library in such a case would be very helpful in the docs.  Something like Sean's value semantics document example.  For that matter, you could reimplement his document example using your library and provide draw concept and copy on write concept for types used instead of relying on inheritance.

Regards,
Luke




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

Re: Formal Review Request: TypeErasure

Daniel Larimer
I read the docs as this library is very impressive and does some of the same things I do with Boost.Reflect so I can appreciate the problem domain.

http://bytemaster.github.com/boost_reflect/group__boost__reflect__quickstart.html#boost_reflect_erasures

I would like to make comments / ask some questions:

1) More motivating examples would be useful.   Given the difficulty (verbosity/boiler plate) of implementing 'push_back', I cannot imagine using this library as an 'end coder' for custom interfaces.  The only place I could see using anything other than the built in concepts would be to simplify the development of my own APIs for my users sake, not mine.

1.1) better documentation on what all of the template parameters mean and why they are used would be helpful.

2) I cannot begin to imagine the template errors generated by using such a complex type.  But this is par for the course with Boost.

3) How does using such an erasure effect compile times?

4) It is difficult to tell from the documentation, but what is the cost of dispatching methods via the any interface?  

5) Many scripting languages have a generic value that could be an int, double, string, bool, array, map, or function.   This could perhaps belong to a new type... boost::type_erasure::variant<conceptA,conceptB,etc>

I have recently been working on a new interface along those lines:
https://github.com/bytemaster/boost_reflect/blob/master/tests/value_test.cpp

struct sub_val {
   std::string happy;
  double      day;
};
BOOST_REFLECT( sub_val, (happy)(day) );

struct test {
  std::string b;
  sub_val     sub;
  std::vector<sub_val> data;
};
BOOST_REFLECT( test, (a)(b)(sub)(data) )

test t(1,"test_ref");
t.sub.happy = "oh happy pie day";

value_cref v(t); // const ref
value vc(t); // copy
value_ref vr(t); // regular ref

BOOST_ASSERT( v["sub"]["happy"].as<std::string>() == "oh happy pie day" );

Yours has compile-time checking and supports many more concepts.  Mine does runtime checking and throws on error.

I would like to compare your approach with mine in boost::reflect to show various tradeoffs.  

I think our work has different strengths and weaknesses and I would love to find a way to blend it.

Compare:
struct vector_concept {
        void push_back( int );
        void push_front (int);
        int size();
        int front();
        int at(int);
};
BOOST_REFLECT_ANY( vector_concept, (push_back)(push_front)(size)(front)(at) )

boost::reflect::any_ptr<vector_concept>  v( new std::vector<int>() );
v->push_back(5);

The way I see it, I was able to define 5+ methods on an interface in one line of easy to understand code.  If you could achieve something like this with your library then it would be a huge win.
Mine is implemented in a manner that results in sizeof(reflect::any_ptr) to grow with each member such as 'push_back' is really a public member functor.  Your approach does not have this overhead.
My approach allows visiting each member and dynamically specifying an implementation.  Yours enables many more concepts (operators, etc) to be implemented.   Mine could be used by any coder, yours requires one that can throughly understand templates and debug all manner of 'place holders'.   I consider myself skilled and would expect to have trouble implementing something like push_back, especially if it required complex usage of place holders.  Better documentation could help.

Clearly we are solving slightly different problems, and I would love to use your library as a high performance, lower overhead version of my reflect::any_ptr<>  class in places where I do not need some of the more dynamic features.

Good job!   I would probably vote to include it based upon the built-in concepts alone.   Some fancy macro help would seal the deal.

Dan


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

Re: Formal Review Request: TypeErasure

Steven Watanabe-4
AMDG

On 05/23/2012 11:27 PM, Daniel Larimer wrote:

> I read the docs as this library is very impressive and does some of the same things I do with Boost.Reflect so I can appreciate the problem domain.
>
> http://bytemaster.github.com/boost_reflect/group__boost__reflect__quickstart.html#boost_reflect_erasures
>
> I would like to make comments / ask some questions:
>
> 1) More motivating examples would be useful.   Given the difficulty (verbosity/boiler plate) of implementing 'push_back', I cannot imagine using this library as an 'end coder' for custom interfaces.  The only place I could see using anything other than the built in concepts would be to simplify the development of my own APIs for my users sake, not mine.
>
> 1.1) better documentation on what all of the template parameters mean and why they are used would be helpful.
>
> 2) I cannot begin to imagine the template errors generated by using such a complex type.  But this is par for the course with Boost.
>

It isn't as bad as you might think and I
know how to change the library to keep the
template instantation depth for the most
common errors down to 3 or 4.

> 3) How does using such an erasure effect compile times?
>

It's fairly slow.  I've made no attempt to
optimize the metaprogramming at this point.

> 4) It is difficult to tell from the documentation, but what is the cost of dispatching methods via the any interface?  
>

The cost is one call through a function pointer.

> 5) Many scripting languages have a generic value that could be an int, double, string, bool, array, map, or function.   This could perhaps belong to a new type... boost::type_erasure::variant<conceptA,conceptB,etc>
>

I'd say that this is out of scope for my
library currently.

> I have recently been working on a new interface along those lines:
> https://github.com/bytemaster/boost_reflect/blob/master/tests/value_test.cpp
>
> struct sub_val {
>    std::string happy;
>   double      day;
> };
> BOOST_REFLECT( sub_val, (happy)(day) );
>
> struct test {
>   std::string b;
>   sub_val     sub;
>   std::vector<sub_val> data;
> };
> BOOST_REFLECT( test, (a)(b)(sub)(data) )
>
> test t(1,"test_ref");
> t.sub.happy = "oh happy pie day";
>
> value_cref v(t); // const ref
> value vc(t); // copy
> value_ref vr(t); // regular ref
>
> BOOST_ASSERT( v["sub"]["happy"].as<std::string>() == "oh happy pie day" );
>
> Yours has compile-time checking and supports many more concepts.  Mine does runtime checking and throws on error.
>
> I would like to compare your approach with mine in boost::reflect to show various tradeoffs.  
>

Reflection is really a separate issue.

> I think our work has different strengths and weaknesses and I would love to find a way to blend it.
>
> Compare:
> struct vector_concept {
> void push_back( int );
> void push_front (int);
> int size();
> int front();
> int at(int);
> };
> BOOST_REFLECT_ANY( vector_concept, (push_back)(push_front)(size)(front)(at) )
>
> boost::reflect::any_ptr<vector_concept>  v( new std::vector<int>() );
> v->push_back(5);
>

This is a nice interface, but it has several
limitations that I see no way around:

a) It supports member functions only
b) Overloading is impossible

Some problems can be solved with difficulty:

c) there's no way to know the number of arguments
   at preprocessing time, so you can't declare
   a regular function.

I think it would be possible to have a macro
that acts something like this for simple cases, though.

> The way I see it, I was able to define 5+ methods on an interface in one line of easy to understand code.  If you could achieve something like this with your library then it would be a huge win.
> Mine is implemented in a manner that results in sizeof(reflect::any_ptr) to grow with each member such as 'push_back' is really a public member functor.  Your approach does not have this overhead.
> My approach allows visiting each member and dynamically specifying an implementation.  Yours enables many more concepts (operators, etc) to be implemented.   Mine could be used by any coder, yours requires one that can throughly understand templates and debug all manner of 'place holders'.   I consider myself skilled and would expect to have trouble implementing something like push_back, especially if it required complex usage of place holders.  Better documentation could help.
>
> Clearly we are solving slightly different problems, and I would love to use your library as a high performance, lower overhead version of my reflect::any_ptr<>  class in places where I do not need some of the more dynamic features.
>
> Good job!   I would probably vote to include it based upon the built-in concepts alone.   Some fancy macro help would seal the deal.
>

I did use macros in the implementation.
Something like this wouldn't be very
hard to implement:

BOOST_TYPE_ERASURE_MEMBER(push_back, 2)
BOOST_TYPE_ERASURE_MEMBER(push_front, 2)

In Christ,
Steven Watanabe

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

Re: Formal Review Request: TypeErasure

Daniel Larimer

On May 24, 2012, at 12:48 PM, Steven Watanabe wrote:

> Reflection is really a separate issue.
>
>> I think our work has different strengths and weaknesses and I would love to find a way to blend it.
>>
>> Compare:
>> struct vector_concept {
>> void push_back( int );
>> void push_front (int);
>> int size();
>> int front();
>> int at(int);
>> };
>> BOOST_REFLECT_ANY( vector_concept, (push_back)(push_front)(size)(front)(at) )
>>
>> boost::reflect::any_ptr<vector_concept>  v( new std::vector<int>() );
>> v->push_back(5);
>>
>
> This is a nice interface, but it has several
> limitations that I see no way around:
>
> a) It supports member functions only
        - does yours support member variables?
        - or are you referring to more general concepts (operators, free functions, etc)

> b) Overloading is impossible
        - not quite, you would have to extend the macro to enumerate the signature of each method.  I did this in prior versions of the code.  

> Some problems can be solved with difficulty:
>
> c) there's no way to know the number of arguments
>   at preprocessing time, so you can't declare
>   a regular function.
        that would be difficult.

> that acts something like this for simple cases, though.
>
>> The way I see it, I was able to define 5+ methods on an interface in one line of easy to understand code.  If you could achieve something like this with your library then it would be a huge win.
>> Mine is implemented in a manner that results in sizeof(reflect::any_ptr) to grow with each member such as 'push_back' is really a public member functor.  Your approach does not have this overhead.
>> My approach allows visiting each member and dynamically specifying an implementation.  Yours enables many more concepts (operators, etc) to be implemented.   Mine could be used by any coder, yours requires one that can throughly understand templates and debug all manner of 'place holders'.   I consider myself skilled and would expect to have trouble implementing something like push_back, especially if it required complex usage of place holders.  Better documentation could help.
>>
>> Clearly we are solving slightly different problems, and I would love to use your library as a high performance, lower overhead version of my reflect::any_ptr<>  class in places where I do not need some of the more dynamic features.
>>
>> Good job!   I would probably vote to include it based upon the built-in concepts alone.   Some fancy macro help would seal the deal.
>>
>
> I did use macros in the implementation.
> Something like this wouldn't be very
> hard to implement:
>
> BOOST_TYPE_ERASURE_MEMBER(push_back, 2)
> BOOST_TYPE_ERASURE_MEMBER(push_front, 2)
>
What does the number 2 mean?   I think this would be great.

Good work, I will probably find use for your library in my own projects.

Dan

> In Christ,
> Steven Watanabe
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


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

Re: Formal Review Request: TypeErasure

Jeremy Maitin-Shepard-2
In reply to this post by Steven Watanabe-4
Steven Watanabe <watanabesj <at> gmail.com> writes:

>
> AMDG
>
> I'd like to request a formal review of the
> TypeErasure library that I've posted about
> several times before here.
>
> The TypeErasure library is a generalization
> of boost::any and boost::function.  It
> allows easy composition of arbitrary
> type erased operators.

This library is indeed very interesting.  From a quick look at some of the
documentation, I have just one initial comment: I believe it is a mistake to
"propagate constness" for "any"s that capture references, as that is
inconsistent with normal C++ semantics and it leads to a situation of trying to
fight the C++ type system rather than work with it.



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

Re: Formal Review Request: TypeErasure

lcaminiti
In reply to this post by Steven Watanabe-4
Steven Watanabe-4 wrote
AMDG

On 05/23/2012 07:12 PM, lcaminiti wrote:
>
> Hello Steven,
>
> I quickly read the docs (see a couple of minor comments below). I'll compile
> and play with the examples this weekend.
>
> I'm interested in the library. If you are looking for a Review Manager, I'd
> like to volunteer if that's OK with you and the Review Wizards.
>

It sounds good to me.  You're a library author,
so I'm sure the Review Wizard will be okay with it.

> Minor Comments
>
> 1) It'd be nice to have a motivating example up front (something not trivial
> but not as complex as the range formatter either).
>

What about something based on any_printable?

typedef any<
  mpl::vector<
    copy_constructible<>,
    typeid_<>,
    ostreamable<> > > any_printable;

I believe that this has come up somewhere.
("Why can't I print boost::any to std::cout?")
Is this about the level of complexity
that you're thinking?
Even somethings a bit more complex but printable is OK too. I will use the lib in some use cases that I ran into the past and let you know if I find a nice example not too complex (I don't remember what the use cases were but they were about type erasure).

> 2) Why placeholders _a, _b, ... instead of _1, _2, ...?
>

Because they represent named arguments, not
positional arguments.  I used _1, _2, etc.
in an earlier version of the library, and
some people were confused about how they
related to _1, _2 in Boost.Bind and Boost.MPL
Got it. I missed that from the docs...

> 3) I found the syntax of concept_interface difficult to understand... for
> example, Base looks arbitrary. But then it's very nice to be able to
> c.push_back(10) instead of call(...)
>
> 4) Same for overloaded concept_interface where both Base and Enable look
> arbitrary. (I wonder if macros could generate some of the boiler-plate code
> for the overload.)
>

Did you look at the doxygen/boostbook reference
for concept_interface?  Is that sufficiently clear?

I realize that my descriptions in the examples
are often a bit sparse.  Would something like
this be clearer?  Do you think it's too verbose?

in custom.cpp:
    This works, but we'd really like to call `c.push_back(10)`.
    We can add members to __any by specializing __concept_interface.
    The first argument is `push_back`, since we want to inject a member
    into every __any that uses the `push_back` concept.  The second
argument,
    Base, is used by the library to chain multiple uses of
__concept_interface
    together.  We have to inherit from it publicly.  Other than
    that we can ignore it.  The third argument is the placeholder
    that represents this any.  If someone used `push_back<_c, _b>`,
    we only want to insert a `push_back` member in the container,
    not the value type.  Thus, the third argument is the container
    placeholder.

in overload.cpp:
    This uses SFINAE to detect whether a using declaration is
    needed.  Note that the fourth argument of __concept_interface
    is a dummy parameter which is always void and is
    intended to be used for SFINAE.
Maybe I used the wrong term in saying "arbitrary". I meant it looks arbitrary to users because it essentially just exposes a library implementation detail (but it's clear it's a "special" base that the lib needs you to put there for the implementation to work). There is probably no way for getting rid of Base, Enable, etc but to use macros. I think macros would be a nice addition as an alternative to define concepts in your lib. I'll see what macro syntax could be implemented (especially with variadic macros, we can do a lot of nice stuff).

> 5) There's a FIXME in the Reserved Identifier section.
>

Yeah.  I haven't come up with any scheme that
covers all the identifiers I want to be able to
use without being too broad.  I suppose I can
always ignore the issue until problems surface
like everyone else.
Thanks.
--Lorenzo
Reply | Threaded
Open this post in threaded view
|

Re: Formal Review Request: TypeErasure

Steven Watanabe-4
In reply to this post by Jeremy Maitin-Shepard-2
AMDG

On 05/24/2012 04:21 PM, Jeremy Maitin-Shepard wrote:

> Steven Watanabe <watanabesj <at> gmail.com> writes:
>
>>
>> I'd like to request a formal review of the
>> TypeErasure library that I've posted about
>> several times before here.
>>
>> The TypeErasure library is a generalization
>> of boost::any and boost::function.  It
>> allows easy composition of arbitrary
>> type erased operators.
>
> This library is indeed very interesting.  From a quick look at some of the
> documentation, I have just one initial comment: I believe it is a mistake to
> "propagate constness" for "any"s that capture references, as that is
> inconsistent with normal C++ semantics and it leads to a situation of trying to
> fight the C++ type system rather than work with it.
>

The situation is one that isn't even
allowed with C++ references:

int & const ref = i; // error

The problem with
const any<Concept, _self&> xx;
is that anything that isn't specially
designed to handle it will see the
const and treat it as const.  Some
parts of the library will work with
it, but in others it was just too
difficult.

In Christ,
Steven Watanabe

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

Re: Formal Review Request: TypeErasure

Jeremy Maitin-Shepard-2
Steven Watanabe <watanabesj <at> gmail.com> writes:
> On 05/24/2012 04:21 PM, Jeremy Maitin-Shepard wrote:
> > Steven Watanabe <watanabesj <at> gmail.com> writes:

[snip]
> The situation is one that isn't even
> allowed with C++ references:
>
> int & const ref = i; // error

True, but a reference can be a member of a struct to which you have a const
reference, in which case it is treated just like a pointer, i.e. no const
propagation.

>
> The problem with
> const any<Concept, _self&> xx;
> is that anything that isn't specially
> designed to handle it will see the
> const and treat it as const.  Some
> parts of the library will work with
> it, but in others it was just too
> difficult.

I can see now that there would be a problem with using concept_interface to
inject member functions, since there is no way to simultaneously define both a
const and non-const member function.  Particularly with the introduction of
member reference qualification, not being able to template on the type of
"this" is a significant defect in the language.  At least it can be worked
around by not using member functions (except for operator overloading where it
can't be avoided).

Maybe support for _self* or even shared_ptr<_self> (as a special syntax to
indicate that internally a shared_ptr to the underlying type should be stored)
could be a useful alternative?



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

Re: Formal Review Request: TypeErasure

John Bytheway-2
On 26/05/12 21:25, Jeremy Maitin-Shepard wrote:

> Steven Watanabe <watanabesj <at> gmail.com> writes:
>> The problem with
>> const any<Concept, _self&> xx;
>> is that anything that isn't specially
>> designed to handle it will see the
>> const and treat it as const.  Some
>> parts of the library will work with
>> it, but in others it was just too
>> difficult.
>
> I can see now that there would be a problem with using concept_interface to
> inject member functions, since there is no way to simultaneously define both a
> const and non-const member function.  Particularly with the introduction of
> member reference qualification, not being able to template on the type of
> "this" is a significant defect in the language.  At least it can be worked
> around by not using member functions (except for operator overloading where it
> can't be avoided).

In the past I've achieved this by defining both const and non-const
member functions and forwarding to a free function which then can be
templated on the type of this.  As you say, things get worse with member
reference qualification because now three member functions are needed.
I don't know whether such a technique would be applicable in this case.

John


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

Re: Formal Review Request: TypeErasure

Dave Abrahams
In reply to this post by Simonson, Lucanus J

on Thu May 24 2012, "Simonson, Lucanus J" <lucanus.j.simonson-AT-intel.com> wrote:

> Steven Watanabe wrote:
>
>> I'd like to request a formal review of the TypeErasure library that I've posted about several times before here.
>>The TypeErasure library is a generalization of boost::any and
>> boost::function.  It allows easy composition of arbitrary type
>> erased operators.
>
> It seems the library is a little more than that.  Have you considered
> naming it Boost.DuckTyping?  I think TypeErasure doesn't really
> capture the full scope of what you've done.

-1

IMO DuckTyping is an ill-defined term that is sometimes used to hide a
multitude of sins.

--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com


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

Re: Formal Review Request: TypeErasure

Dave Abrahams
In reply to this post by Steven Watanabe-4

on Tue May 22 2012, Steven Watanabe <watanabesj-AT-gmail.com> wrote:

>
> Online documentation can be found here:
> http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/

http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/doc/html/boost_typeerasure/multi.html
says:

  The types of the arguments must match or the behavior is undefined.

I presume you mean that the dynamic, erased types must match?
(presumably you could easily prevent the use of different static types at
compile-time).  IMO it's crucial that you be rigorous about these
distinctions in your documentation.

I wonder if undefined behavior is really the best possible choice here.
I honestly don't know what's most useful.  Do you have a rationale for
your choice?

Also, I must add that the following sentence is so diametrically opposed
to the one above that putting it in a different paragraph doesn't help
the reader enough to deal with the cognitive dissonance:

  The operands do not all have to be the same type.

Cheers,

--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com


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

Re: Formal Review Request: TypeErasure

Dave Abrahams
In reply to this post by Steven Watanabe-4

on Tue May 22 2012, Steven Watanabe <watanabesj-AT-gmail.com> wrote:

> Online documentation can be found here:
> http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/

http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/doc/html/boost_typeerasure/references.html
starts using two things out of the blue that you haven't introduced yet:

1. any<...> with template arguments that aren't mpl sequences
2. _self

IMO that should be corrected.

--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com


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

Re: Formal Review Request: TypeErasure

Simonson, Lucanus J
In reply to this post by Dave Abrahams
Dave Abrahams wrote:

>> Steven Watanabe wrote:
>>
>>> I'd like to request a formal review of the TypeErasure library that I've posted about several times before here.
>>>The TypeErasure library is a generalization of boost::any and  
>>boost::function.  It allows easy composition of arbitrary type  erased
>>operators.
>>
>> It seems the library is a little more than that.  Have you considered
>> naming it Boost.DuckTyping?  I think TypeErasure doesn't really
>> capture the full scope of what you've done.

>IMO DuckTyping is an ill-defined term that is sometimes used to hide a multitude of sins.

Yes, after making that post I thought about it a little more and decided I don't know how to define duck typing, but I know it when I see it.

If it walks like a duck and it talks like a duck, then it's a duck.  Until it doesn't talk like a duck, then it's a run time error.  That's not a language feature we want, and it's not what the library implements.

Primarily it seems the library is adding a layer of type checking on top of type erasure.  Boost.Any does type erasure.  This library does more.  I'd like the combination of static polymorphism and type erasure to have a name.  ConceptAny, DynamicConcepts, AnnonymousConcepts, TypeSafeAny.

Regards,
Luke



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

Re: Formal Review Request: TypeErasure

Ron Garcia
In reply to this post by Steven Watanabe-4
Hi Steven,

I have received your request and will add it to the review schedule.

Best,
Ron

On May 22, 2012, at 4:34 PM, Steven Watanabe wrote:

> AMDG
>
> I'd like to request a formal review of the
> TypeErasure library that I've posted about
> several times before here.
>
> The TypeErasure library is a generalization
> of boost::any and boost::function.  It
> allows easy composition of arbitrary
> type erased operators.
>
> As an example of basic usage, we
> can simulate Boost.Any:
>
> any<mpl::vector<copy_constructible<>, typeid_<> > > x(10);
> int i = any_cast<int>(x); // i == 10
>
> The library is available in the Boost Sandbox at
> http://svn.boost.org/svn/boost/sandbox/type_erasure/
>
> You can download archives with pre-built documentation from
> http://sourceforge.net/projects/steven-watanabe.u/files/
>
> Online documentation can be found here:
> http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/
>
> In Christ,
> Steven Watanabe
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
1234 ... 7