gmane.comp.lib.boost.devel

Re: Formal Review Request: TypeErasure

Daniel Larimer — 2012-05-24T17:11:59

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

- does yours support member variables? 
- or are you referring to more general concepts (operators, free functions, etc)

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

that would be difficult.

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



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

Re: Formal Review Request: TypeErasure

Steven Watanabe — 2012-05-24T16:48:22

AMDG

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

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.


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


The cost is one call through a function pointer.


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


Reflection is really a separate issue.


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.


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

Re: Release notes for 1.50

lcaminiti — 2012-05-24T15:24:58

Daniel James-3 wrote

I've committed release notes for ScopeExit (new features), LocalFunciton
(new library), Functional/OverloadedFunction (new library),
Utility/IdentityTtpe (new library).

I did not generate the HTML so please fix my QuickBook entries in case
there's any error (but they should be OK).




Thanks.
--Lorenzo


--
View this message in context: http://boost.2283326.n4.nabble.com/Release-notes-for-1-50-tp4630401p4630461.html
Sent from the Boost - Dev mailing list archive at Nabble.com.

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

regression tests fail with no error?

lcaminiti — 2012-05-24T12:35:15

Hello all,

Some of my library regression tests occasionally fail like this:

http://www.boost.org/development/tests/release/developer/Sandia-darwin-intel-11-1-local_function-intel-darwin-11-1-add_except_seq-variants_.html

If you follow the link, there is no actual error. Plus the tests sometimes
it fails (with no actual error) and other times it passes (as it should).

Is this just a problem with the regression test parsing script?

Thanks a lot.
--Lorenzo


--
View this message in context: http://boost.2283326.n4.nabble.com/boost-regression-tests-fail-with-no-error-tp4630458.html
Sent from the Boost - Dev mailing list archive at Nabble.com.

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

Re: Formal Review Request: TypeErasure

Daniel Larimer — 2012-05-24T06:27:13

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

Re: Release notes for 1.50

Daniel James — 2012-05-24T04:58:50

They're up now. We used to try to avoid changing the release notes
after they'd gone live because it caused a lot of noise in people's
rss feeds. But that's less of a problem since I added link and guid
elements to feed items.

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

Re: Formal Review Request: TypeErasure

Simonson, Lucanus J — 2012-05-24T04:52:30


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

Re: Formal Review Request: TypeErasure

Steven Watanabe — 2012-05-24T03:53:19

AMDG

On 05/23/2012 07:12 PM, lcaminiti wrote:

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


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?


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


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.


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

Re: Formal Review Request: TypeErasure

Nathan Ridge — 2012-05-24T02:26:44


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

Re: Formal Review Request: TypeErasure

lcaminiti — 2012-05-24T02:12:54

Steven Watanabe-4 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.

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


--
View this message in context: http://boost.2283326.n4.nabble.com/Formal-Review-Request-TypeErasure-tp4630373p4630451.html
Sent from the Boost - Dev mailing list archive at Nabble.com.

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

Re: [1.50.0] RELEASE BRANCH REOPENED (was: Beta schedule)

lcaminiti — 2012-05-24T01:39:58

lcaminiti wrote

Done. I will be watching the release regression tests very closely for the
next few days.

Thanks a lot.
--Lorenzo


--
View this message in context: http://boost.2283326.n4.nabble.com/1-50-0-Beta-schedule-tp4630328p4630450.html
Sent from the Boost - Dev mailing list archive at Nabble.com.

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

Re: [1.50.0] RELEASE BRANCH REOPENED

Eric Niebler — 2012-05-23T22:15:15

Thanks, Jeremiah.

Re: [1.50.0] RELEASE BRANCH REOPENED

Jeremiah Willcock — 2012-05-23T22:00:52


I tried to do the merge, then realized that some of my changes depend on 
TypeTraits Introspection which apparently hasn't been merged yet.  Because 
of that and trouble I had getting other things to work after the merge, 
I'll wait until 1.51.

Re: [MSM] Single event, multiple orthogonal submachines

Christophe Henry — 2012-05-23T20:58:25

You don't need to do anything. If every submachine is in its own orthogonal 
region, then MSM gives each of them a chance to process the event (in the 
order defined by your initial_state typedef). And if some are not 
interested, nothing bad happens, only the interested regions will process.


I think you're doing it right. If you also provide a MSM flag in isMoving, 
you'll be able to check its status in RunSystem.
The only thing is that submachines are compile-time-intensive. If it becomes 
too bad, you might have to switch to regions without submachines. They won't 
be reusable but otherwise they'll do the same job.


Cheers!
Christophe



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

Re: [1.50.0] RELEASE BRANCH REOPENED (was: Beta schedule)

lcaminiti — 2012-05-23T20:57:16

Beman Dawes wrote

Will do. I'll merge by tonight.

Thanks.
--Lorenzo


--
View this message in context: http://boost.2283326.n4.nabble.com/1-50-0-Beta-schedule-tp4630328p4630443.html
Sent from the Boost - Dev mailing list archive at Nabble.com.

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

Re: [1.50.0] RELEASE BRANCH REOPENED

Beman Dawes — 2012-05-23T20:45:16

Do the merge locally, and test on any compilers you have access to. If
that's OK, commit the merge, but revert if any regression tests fail
unexpectedly and the fixes aren't trivial or can't be applied right
away.

--Beman

--Beman

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

Re: [Review Request] Inclusion of the Boost.PolygonVoronoiLibrary

Phil Endecott — 2012-05-23T20:37:16

Ah yes, I'd forgotten that.  But construct_voronoi is just a 3-line 
function that does what I was doing.  In my case, it was simpler to 
call insert() inside a for loop rather than trying to create some sort 
of range adaptor to pass to the free function.


Regards,  Phil.






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

Re: [1.50.0] RELEASE BRANCH REOPENED (was: Beta schedule)

Beman Dawes — 2012-05-23T20:16:02

That sounds OK to me; you have the risks pretty well covered. Several
other release managers are also in favor of a go ahead, so please
merge to release ASAP and keep a close eye on the release regression
tests.

Thanks,

--Beman

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

Re: [1.50.0] RELEASE BRANCH REOPENED

Jeremiah Willcock — 2012-05-23T20:12:11


The main change is that I refactored the handling of properties stored 
inside graphs, so it is somewhat extensive.  It did seem to work on the 
full list of platforms relatively quickly.  I have not tried to do a merge 
locally yet, but I'd do that before I committed any changes.

Re: Revelations at C++Now!?

Beman Dawes — 2012-05-23T20:10:12

Yep, and reality is taking the form of a backup of both Boost and
non-Boost tasks to be accomplished.


Lots! The steering committee met several times.


Be a day or two more before we get a chance to post details. Stay tuned!

--Beman

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

Re: [Review Request] Inclusion of the Boost.PolygonVoronoiLibrary

Simonson, Lucanus J — 2012-05-23T19:54:50

Andrii Sydorchuk


I think a single index would be simpler on our side and if the user requires different data types for point and segment they can handle that on their end with a simple abstraction on top of the index such as indexing to a boost any.  Having two different types of index doesn't enable anything, it simply makes one specific use case more convenient.  Common use cases will be only points or only segments in the input, so complicating the interface for the mixed case seems like over design.

Regards,
Luke

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