*smgreened | 15 Aug 2012 15:49

[Interest] Value Dispatch

Hi all,

This might be old hat to verteran boosters but I found it nifty.  Maybe
it could make a small addition to Boost.

Inspired by Sean Parent's C++Now! talk and the various articles on
cpp-next, I've been playing around with value semantics and C++11.

I found an interesting use of pack expansion at stackoverflow and
expanded on it in a local project to convert from a traditional
inheritance/virtual function model to a more value-centered approach.

It turns out that with pack expansion one can implement "virtual
functions" without needing inheritance or pointer/reference semantics.
One can consider a vrtual function as "just" a compiler-generated switch
statement.  With that in mind, here's an example:

-----------

#include <iostream>

/// This is a collection of node kinds.  We use it to categorize
/// various kinds of objects and dispatch to the correct routine.
template<typename T, typename T::kind ...I>
class kind_tuple {};

/// This is the "virtual function" dispatch mechanism.  It
/// statically generates a lookup table of routines, one for each
/// kind.
template<typename R, typename D, typename T>
(Continue reading)

Larry Evans | 15 Aug 2012 20:06

Re: [Interest] Value Dispatch

On 08/15/12 08:49, *smgreened <at> obbligato.org wrote:
> Hi all,
> 
> This might be old hat to verteran boosters but I found it nifty.  Maybe
> it could make a small addition to Boost.
> 
> Inspired by Sean Parent's C++Now! talk and the various articles on
> cpp-next, I've been playing around with value semantics and C++11.
> 
> I found an interesting use of pack expansion at stackoverflow and
> expanded on it in a local project to convert from a traditional
> inheritance/virtual function model to a more value-centered approach.
> 
> It turns out that with pack expansion one can implement "virtual
> functions" without needing inheritance or pointer/reference semantics.
> One can consider a vrtual function as "just" a compiler-generated switch
> statement.  With that in mind, here's an example:
> 
> -----------
[snip]
> class vehicle {
> public:
>   enum kind {
>     Car,
>     Bus,
>     Boat,
>     Train,
>     Airplane
>   };
> 
(Continue reading)

greened | 16 Aug 2012 03:34

Re: [Interest] Value Dispatch

[Note: I don't know why my e-mail address got mangled.  It should be
 "greened <at> ..."]

Larry Evans <cppljevans <at> suddenlink.net> writes:

> Could you not use boost::variant

Thanks for your feedback!

boost::variant can do some similar things but I think it is really aimed
at a different problem.  As I understand it, boost::variant's primary
use case is to function as a type safe generalized union.  Thus it has
to deal with things like alignment, etc. that the presented technique
(which I call "value dispatch" for lack of a better name) does not.  A
quick glance at boost::variant source code shows that it is quite
complex.  IMHO, value dispatch is much simpler.

I was aiming for a value-centered analogue to virtual functions as
opposed to an enhanced union type.  boost::variant feels opaque to me
(get<>, etc.) while value dispatch seems more natural and transparent
for the use cases I had in mind.

Note also that boost::variant appears to require or at least encourage
inheritance (e.g. static_visitor) while value dispatch does not.  I
don't think that's a strong positive or negative as long as value
semantics are maintained.

That said, I'll now explain how I think inheritance might be useful with
value dispatch.  :)

(Continue reading)

Larry Evans | 16 Aug 2012 05:00

Re: [Interest] Value Dispatch

On 08/15/12 20:34, greened <at> obbligato.org wrote:
> [Note: I don't know why my e-mail address got mangled.  It should be
>  "greened <at> ..."]
> 
> Larry Evans <cppljevans <at> suddenlink.net> writes:
> 
>> Could you not use boost::variant
> 
> Thanks for your feedback!
> 
> boost::variant can do some similar things but I think it is really aimed
> at a different problem.  As I understand it, boost::variant's primary
> use case is to function as a type safe generalized union.  Thus it has
> to deal with things like alignment, etc. that the presented technique
> (which I call "value dispatch" for lack of a better name) does not. 

But the only reason why value dispatch does not have to deal with
alignment is because the values are all empty.  The only member
values in vehicle is the tag:

  kind the_kind;

As soon as you have to add other member variables (I assume a real
Boat or a real Plane would have other member variables), you'll have to
deal with alignment, if you want to save space.

> A
> quick glance at boost::variant source code shows that it is quite
> complex.  IMHO, value dispatch is much simpler.

(Continue reading)

greened | 16 Aug 2012 06:32

Re: [Interest] Value Dispatch

Larry Evans <cppljevans <at> suddenlink.net> writes:

> But the only reason why value dispatch does not have to deal with
> alignment is because the values are all empty.  The only member
> values in vehicle is the tag:
>
>   kind the_kind;
>
> As soon as you have to add other member variables (I assume a real
> Boat or a real Plane would have other member variables), you'll have to
> deal with alignment, if you want to save space.

I wrote value dispatch precisely for the case where one doesn't have to
save space.  The particular project I'm using this for previously used
inheritance and virtual functions pretty much for the dispatch/compiler
generated switch stuff.  They all share identical (template)
implementations and all had the same size.

Even so, nothing would prevent a plan ol' union in the classes, right?
You'll even be dispatched to a function that knows exactly which member
is the right one.

                           -Dave

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

Steven Watanabe | 16 Aug 2012 05:36
Picon

Re: [Interest] Value Dispatch

AMDG

On 08/15/2012 06:34 PM, greened <at> obbligato.org wrote:
> 
> I was aiming for a value-centered analogue to virtual functions as
> opposed to an enhanced union type.

Well, what you have is essentially a union type,
even if that's not what you intended.

>  boost::variant feels opaque to me
> (get<>, etc.) while value dispatch seems more natural and transparent
> for the use cases I had in mind.
> 

You should avoid using get<> on a variant.
Whenever possible, apply_visitor is better.

> Note also that boost::variant appears to require or at least encourage
> inheritance (e.g. static_visitor) while value dispatch does not.  I
> don't think that's a strong positive or negative as long as value
> semantics are maintained.
> 

Boost.Variant doesn't care about inheritance.
static_visitor is like std::iterator or
std::binary_function.  It's just a helper
that provides a result_type typedef.
Anyway, static_visitor is for apply_visitor
and doesn't have anything to do with the
(Continue reading)

greened | 16 Aug 2012 06:40

Re: [Interest] Value Dispatch

Steven Watanabe <watanabesj <at> gmail.com> writes:

> AMDG
>
> On 08/15/2012 06:34 PM, greened <at> obbligato.org wrote:
>>
>> I was aiming for a value-centered analogue to virtual functions as
>> opposed to an enhanced union type.
>
> Well, what you have is essentially a union type,
> even if that's not what you intended.

It entirely depends on how the classes arrange member data, no?  In my
"real" project, the classes all have std::vectors with different kinds
of stuff in them, depending on the kind tag.  The elements all use the
same value dispatch mechanism to implement polymorphism.  In that sense
I guess it's sort of like a union, but certainly not in the traditional
sense.

>>  boost::variant feels opaque to me (get<>, etc.) while value dispatch
>> seems more natural and transparent for the use cases I had in mind.
>
> You should avoid using get<> on a variant.  Whenever possible,
> apply_visitor is better.

That's no less opaque.

>> Note also that boost::variant appears to require or at least
>> encourage inheritance (e.g. static_visitor) while value dispatch does
>> not.  I don't think that's a strong positive or negative as long as
(Continue reading)


Gmane