"Daniel Larimer" <dlarimer@gmail.com> wrote in message news:C97AB2D0.21251%dlarimer@gmail.com...
What trade offs should be made?
As always, (preferably) none :) If in practice some have to be made, for a low level library, 'power' and efficiency are primary concerns...
Macro-based or template-based?
As always, 'avoid macros'...but, again, in practice some amount of macros will probably be unavoidable for a library like this (if verbosity/duplication is to be minimized)...
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'.
As a general possibility/an additional layer this may be useful somewhere (although I can't think of where) but to use/force it as the general implementation for all interfaces would just be a 'genocidal overkill' (regardless of the longevity of the objects)...especially with the current 'not so happy' boost::function implementation (see http://lists.boost.org/Archives/boost/2010/10/172593.php ...)... I'm not even sure where such an 'idiom' would fit or how it would be called as then the individual 'functions' would each have their own state (held in/by a boost::function<> object) as opposed to all sharing a common 'state' - the object whose interface they represent...
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'.
This still wouldn't be a 'struct of pointers' because member function pointers (i.e. their binary representation) are 'implementation defined'...for the defined ABI requirement (that I described two posts ago) plain function pointers would have to be used...
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.
If I understood you correctly, by this you mean the 'static vtable + vtable ptr' approach...? Anyways I'm for having the option of (2) (a contained struct of pointers/vtable) and (3)...If you want, as far as I am concerned, you can add (1) as an option however I must admit I do not see its usefulness...
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.
I'm not sure how this relates to a Boost.Interfaces library..? -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman