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

Subject: Re: [boost] [interfaces] Boost Interface Library (2004?)
From: Domagoj Saric (domagoj.saric_at_[hidden])
Date: 2011-02-11 11:08:27

"Daniel Larimer" <dlarimer_at_[hidden]> wrote in message 
news:C97AB2D0.21251%dlarimer_at_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