"Daniel Larimer" <dlarimer@gmail.com> wrote in message news:6E4BC406-F81F-4DC9-8AD5-A974DC3E7F97@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