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-18 12:12:31

"Daniel Larimer" <dlarimer_at_[hidden]> wrote in message
news:6E4BC406-F81F-4DC9-8AD5-A974DC3E7F97_at_gmail.com...
> I do not like the boost::function problems either, it was more of a
> notional.  There is always
> this(http://www.codeproject.com/KB/cpp/fastdelegate2.aspx)
> drop in replacement for boost::function.   (What do people on this
> list think of these other delegates?).   Then there is the super-fast,
> super-light weight FastDelegate by Don Clugston.

No matter how light it is, a delegate is always fatter than a plain function
pointer...but, more importantly, it has different semantics (the previously
mentioned 'state' issue)...which might not be needed or even appropriate for 
this use case...

> The challenge is that templates are great for calculating types, but
> manipulating
> and creating names is beyond its ability and requires either hand coding
> or the
> pre-processor.  So to create a class with 'shared state' requires creating
> defining a method with a given name and param types.  This can only be
> done if the entire specification uses the pre-processor.
>
> BOOST_TYPE_ERASURE( AnyDevice,
> ( (ReturnType) (method1) ( (int)(arg1), (int)(arg2),.. ) ),
> ( (ReturnType) (method2) ( (int)(arg1), (int)(arg2),.. ) ),
> )
>
> This solution is very similar to what Boost.Interfaces did, everything is
> in the macro.    This can achieve the most efficient solution, but in my
> mind the syntax is so bad that I would never want to touch it.  Dealing
> with commas etc is also hard with these kind of macros.

Nobody likes macros (OK, even in this day and age, many still do, but we are 
not talking about "them" here ;) however at a certain level they become 
unavoidable with current tools and the state of the language. This is why we 
have the (uber excelent) Boost.Preprocessor library...Having accepted that 
fact a long time ago I would not mind the syntax you outlined above...

>  Ideally the
> preprocessor would only specify the names and the template code would
> deduce all of the types.  Unfortunately, I am at a loss on how to
> efficiently let the templates deduce the types for a given name without
> using a macro to specify all possible partial specializations for each
> name resulting in template bloat.

Hm, I kind of lost you there, what partial specializations are you referring 
to?

> If the goal is to maintain a natural syntax, then the public interface
> needs to be used the same way as a natural class.  Thus normal function
> table would not have enough information to deduce the 'this' pointer.

Why not? The this pointer can be stored separately (or deduced in some other 
way, e.g. like boost::function does)...the implementation (with a plain 
struct of plain function pointers or otherwise) in no way implies the 
interface...this is just a private implementation detail that will be 
wrapped in a C++ class...

> Well it falls under the concept of mapping member variables vs member
> functions.   Not polymorphic.   This is actually a much easier problem
> than dealing with the methods.

I must admit I still don't see how this relates to the topic 
(Boost.Interfaces)...

-- 
"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