On 2/11/11 7:32 AM, "Domagoj Saric" <domagoj.saric@littleendian.com> wrote:
"Edward Diener" <eldiener@tropicsoft.com> wrote in message news:iinlb5$thr$1@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