Re: [boost] [interfaces] Boost Interface Library (2004?)

Subject: Re: [boost] [interfaces] Boost Interface Library (2004?)
From: Daniel Larimer (dlarimer_at_[hidden])
Date: 2011-02-11 09:33:04

On 2/11/11 7:32 AM, "Domagoj Saric" <domagoj.saric_at_[hidden]> wrote:

> 
> "Edward Diener" <eldiener_at_[hidden]> wrote in message
> news:iinlb5$thr$1_at_dough.gmane.org...
> 
>> In any case I encourage you to explain the use case(s) of your library as
>> carefully as you can in order to get others interested in it.
> 
> IMO the motivation and explanations listed on the Boost.Interfaces page are
> quite sufficient...
> 
> I would very much welcome the inclusion of a Boost.Interfaces-like library.
> It could provide a way to fix or workaround the limitations of the built-in
> C++ virtual function/dynamic dispatch functionality.

As someone who will be building such an interface, I am very interested on
what you think the requirements should be.  What trade offs should be made?
Macro-based or template-based?

Options:
    1) Each method becomes a public boost::function with the proper
signature.  This completely separates how things can be dispatched at the
expense of the size of the interface object.   Great for long-lived objects,
not so great for small 'structs'.
    2) Each method simply stores a member function pointer that must be
bound to the single 'this' used for all methods.  This uses less memory, but
still is equivalent to a 'struct of pointers'.
    3) Global static mapping, in which case you would end up with something
like today's virtual functions where the 'inheritance' is calculated at
assignment.  

Some ideas that I have been throwing around:

Imagine being able to assign any two structs where the assignment operation
is defined as 'if they both have a field of the same name & convertible
type' then the fields are assigned, otherwise not.  You could have different
policies such as "require all fields" or "optional fields".   I suspect that
such a construct would make creating functions that take 'named parameters'
much easier.

Dan