[interfaces] Boost Interface Library (2004?)
I recently ran across the unofficial Boost Interface Library (http://www.coderage.com/interfaces), but it appears that it is was never adopted nor much discussed since I joined this mailing list. Boost.Interfaces provides a macro-based Interface Definition Language (IDL) which can be used to define C++ class types called interfaces. An interface is a lightweight value type associated with a set of named function signatures. An interface instance can be bound at runtime to any object which implements the interface, i.e., to any object of a type with accessible non-static member functions having the same name and signature as the set of functions associated with the interface. The functions of the bound object can then be invoked through the interface instance using the �dot� operator. Binding is completely non-intrusive: the object's type need not declare any virtual functions or derive from any particluar base class. Interfaces were described in a September 2004 C/C++ Users Journal article by Christopher Diggins. After looking through the library I concluded that I did not like how it was implemented. Too many macros, unnatural syntax. I guess few people liked it enough for it to be kept up to date (6+ years old now). I have also looked at the Boost Mirror library which provides reflection of just about everything at the expense of some nasty macros and no clear path toward defining dynamic interfaces based upon the reflected type information. I think the goal of the interface library should be a more flexible/powerful version of "boost::any" that allows you to define the interface of the object stored in the 'any'. In this way it takes type erasure to a new level. That said, I have a need for developing an interface library that abstracts the differences between direct pointer access, RPC, and asynchronous inter-thread communication. So I have developed and tested a new 'api' for defining interfaces with the hope that it would be considered worthwhile for boost. Goals / Non-Goals 1) Define Interfaces in Natural C++ Syntax 2) Provide the ability to define 'dynamic' implementations of an interface for calling RPC, scripting language interface, etc. 3) Objects that implement 'interfaces' should be long-lasting 'actors' where overhead of creating/copying/destroying the interface along with any memory usage is of secondary importance to the ease of defining dynamic interfaces and achieving 'type erasure'. 4) Ideally each member of an interface is a function object that can be bound to anything. I am interested in feedback on what the API/features should be of a generic interface library to improve upon BIL. Should the interface definition classes be in a namespace such as idl_definition or should the BOOST_IDL_INTERFACE macro place the interface type in an 'idl' namespace? Example: namespace idl_definition { struct SomeBase { // these methods need not be implemented anywhere as they are never called. std::string name()const; }; struct Shape : public SomeBase { double area(int); std::string type(); std::string my_mem; }; } BOOST_IDL_INTERFACE( SomeBase, BOOST_PP_NIL, (name) ) BOOST_IDL_INTERFACE( Shape, (SomeBase,BOOST_PP_NIL), (area) (type) (my_mem) ) class print_api_visitor : public boost::idl::visitor<print_api_visitor> { public: template<typename InterfaceName, typename M> bool accept( M& m, const char* name ) { std::cerr << boost::idl::get_typestring<InterfaceName>::str() << "::" << name << " " << boost::idl::get_typestring<typename M::signature>::str() << (M::is_const ? "const" : "") << std::endl; return true; } }; class Circle { public: std::string name()const{ return "CircleName"; } double area(int v) { return v*3.1415; } std::string type() { return "circle"; } std::string my_mem; }; int main( int argc, char** argv ) { boost::shared_ptr<Circle> c(new Circle()); Shape s = c;//Circle(); //new Circle(); s.my_mem = std::string("HelloWOrld"); std::string tmp = s.my_mem; std::cerr<<"type: "<<s.type() << std::endl; std::cerr<<"area: "<<s.area(3) << std::endl; std::cerr<<"area: "<<*s.my_mem << std::endl; std::cerr<< "9*pi = "<<boost::idl::make_delegate( c.get(), Shape::__idl__area::get_member_on_type<Circle>() )(9) << std::endl; std::cerr<< "my_mem = "<< c.get()->*Shape::__idl__my_mem::get_member_on_type<Circle>() << std::endl; std::cerr<< "my_mem = "<< c.get()->*s.my_mem.get_member_on_type<Circle>() << std::endl; std::cerr<<"print api!\n"; print_api_visitor papi; papi.start(s); Circle* c2 = new Circle; c2->my_mem = "Circle2!!!"; boost::idl::set_delegate_visitor<Circle> sd(c2); sd.start(s); std::cerr<<"c->area: "<< *s.my_mem << std::endl; return 0; } Here is an example of the visitor used to setup the delegate: template<typename T> class set_delegate_visitor : public boost::idl::visitor<set_delegate_visitor<T> > { public: set_delegate_visitor( T* self = 0) :m_self(self){} template<typename InterfaceName, typename M> bool accept( M& m, const char* name ) { m.set_delegate( m_self, M::template get_member_on_type<T>() ); return true; } private: T* m_self; }; Output ==================== type: circle area: 9.4245 area: HelloWOrld c->area: HelloWOrld sizeof(s): 120 9*pi = 28.2735 my_mem = HelloWOrld my_mem = HelloWOrld print api! SomeBase::name std::string()const Shape::area double(int32_t) Shape::type std::string() Shape::my_mem std::string c->area: Circle2!!!
On 2/6/2011 3:07 PM, Daniel Larimer wrote:
I recently ran across the unofficial Boost Interface Library (http://www.coderage.com/interfaces), but it appears that it is was never adopted nor much discussed since I joined this mailing list. Boost.Interfaces provides a macro-based Interface Definition Language (IDL) which can be used to define C++ class types called interfaces. An interface is a lightweight value type associated with a set of named function signatures. An interface instance can be bound at runtime to any object which implements the interface, i.e., to any object of a type with accessible non-static member functions having the same name and signature as the set of functions associated with the interface. The functions of the bound object can then be invoked through the interface instance using the �dot� operator. Binding is completely non-intrusive: the object's type need not declare any virtual functions or derive from any particluar base class.
Interfaces were described in a September 2004 C/C++ Users Journal article by Christopher Diggins.
After looking through the library I concluded that I did not like how it was implemented. Too many macros, unnatural syntax. I guess few people liked it enough for it to be kept up to date (6+ years old now). I have also looked at the Boost Mirror library which provides reflection of just about everything at the expense of some nasty macros and no clear path toward defining dynamic interfaces based upon the reflected type information.
How are is an interface any different than a C++ abstract class ?
Edward Diener <eldiener <at> tropicsoft.com> writes:
On 2/6/2011 3:07 PM, Daniel Larimer wrote:
I recently ran across the unofficial Boost Interface Library (http://www.coderage.com/interfaces),
How are is an interface any different than a C++ abstract class ?
As the concept is defined by the aforementioned library, interfaces allow for dynamic duck typing. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquin M Lopez Munoz wrote:
Edward Diener <eldiener <at> tropicsoft.com> writes:
On 2/6/2011 3:07 PM, Daniel Larimer wrote:
I recently ran across the unofficial Boost Interface Library (http://www.coderage.com/interfaces),
How are is an interface any different than a C++ abstract class ?
As the concept is defined by the aforementioned library, interfaces allow for dynamic duck typing.
Up to version 2.95, GCC had an extension to manage with signatures (See http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_5.html#SEC112). Maybe you can be interested in. Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/interfaces-Boost-Interface-Library-2004-t... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 2/6/2011 4:18 PM, Joaquin M Lopez Munoz wrote:
Edward Diener<eldiener<at> tropicsoft.com> writes:
On 2/6/2011 3:07 PM, Daniel Larimer wrote:
I recently ran across the unofficial Boost Interface Library (http://www.coderage.com/interfaces),
How are is an interface any different than a C++ abstract class ?
As the concept is defined by the aforementioned library, interfaces allow for dynamic duck typing.
It is not your problem but I did not get much of an understanding from the OP's original description of what advantages his implementation has over using C++ abstract classes to define interfaces. In other words what duck typing has to offer in terms of use which makes it better.
On Feb 6, 2011, at 5:58 PM, Edward Diener wrote:
On 2/6/2011 4:18 PM, Joaquin M Lopez Munoz wrote:
Edward Diener<eldiener<at> tropicsoft.com> writes:
On 2/6/2011 3:07 PM, Daniel Larimer wrote:
I recently ran across the unofficial Boost Interface Library (http://www.coderage.com/interfaces),
How are is an interface any different than a C++ abstract class ?
As the concept is defined by the aforementioned library, interfaces allow for dynamic duck typing.
It is not your problem but I did not get much of an understanding from the OP's original description of what advantages his implementation has over using C++ abstract classes to define interfaces. In other words what duck typing has to offer in terms of use which makes it better.
It is not always possible to change the inheritance hierarchy of other types that you want to use in a polymorphic way. Sometimes you need to add a polymorphic interface to a class that you do not want a vtable for. Every method in an abstract class becomes a virtual dispatch even when most use cases do not require or cannot benefit from virtual dispatching. All of those reasons aside, my interest in the subject is because I want to dynamically create stubs for RPC, scripting, etc and there is no way to do that via an abstract class.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 2/6/2011 8:01 PM, Daniel Larimer wrote:
On Feb 6, 2011, at 5:58 PM, Edward Diener wrote:
On 2/6/2011 4:18 PM, Joaquin M Lopez Munoz wrote:
Edward Diener<eldiener<at> tropicsoft.com> writes:
On 2/6/2011 3:07 PM, Daniel Larimer wrote:
I recently ran across the unofficial Boost Interface Library (http://www.coderage.com/interfaces),
How are is an interface any different than a C++ abstract class ?
As the concept is defined by the aforementioned library, interfaces allow for dynamic duck typing.
It is not your problem but I did not get much of an understanding from the OP's original description of what advantages his implementation has over using C++ abstract classes to define interfaces. In other words what duck typing has to offer in terms of use which makes it better.
It is not always possible to change the inheritance hierarchy of other types that you want to use in a polymorphic way. Sometimes you need to add a polymorphic interface to a class that you do not want a vtable for. Every method in an abstract class becomes a virtual dispatch even when most use cases do not require or cannot benefit from virtual dispatching.
So you want the effective of an abstract class without the virtual methods ?
All of those reasons aside, my interest in the subject is because I want to dynamically create stubs for RPC, scripting, etc and there is no way to do that via an abstract class.
There is nothing on the C++ standard about RPC stubs so when you say that there is no way to do that from an abstract class you must be referring to some 3rd party library you are using. I have dealt with RPC in a project I once worked on for Hewlett-Packard but I admit I no longer remember how the IDL was created, or even if it was done manually or programatically. 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.
On Feb 6, 2011, at 9:27 PM, Edward Diener wrote:
On 2/6/2011 8:01 PM, Daniel Larimer wrote:
On Feb 6, 2011, at 5:58 PM, Edward Diener wrote:
On 2/6/2011 4:18 PM, Joaquin M Lopez Munoz wrote:
Edward Diener<eldiener<at> tropicsoft.com> writes:
On 2/6/2011 3:07 PM, Daniel Larimer wrote:
I recently ran across the unofficial Boost Interface Library (http://www.coderage.com/interfaces),
How are is an interface any different than a C++ abstract class ?
As the concept is defined by the aforementioned library, interfaces allow for dynamic duck typing.
It is not your problem but I did not get much of an understanding from the OP's original description of what advantages his implementation has over using C++ abstract classes to define interfaces. In other words what duck typing has to offer in terms of use which makes it better.
It is not always possible to change the inheritance hierarchy of other types that you want to use in a polymorphic way. Sometimes you need to add a polymorphic interface to a class that you do not want a vtable for. Every method in an abstract class becomes a virtual dispatch even when most use cases do not require or cannot benefit from virtual dispatching.
So you want the effective of an abstract class without the virtual methods ?
All of those reasons aside, my interest in the subject is because I want to dynamically create stubs for RPC, scripting, etc and there is no way to do that via an abstract class.
There is nothing on the C++ standard about RPC stubs so when you say that there is no way to do that from an abstract class you must be referring to some 3rd party library you are using.
You can create an abstract class, but it requires code generation or manually coding the RPC stub that inherits from the abstract class. I have a strong dislike for anything that requires code generation because it is fragile and introduces extra complexity to your build process.
I have dealt with RPC in a project I once worked on for Hewlett-Packard but I admit I no longer remember how the IDL was created, or even if it was done manually or programatically.
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.
Suppose you had a calculator class that you want to expose as an RPC service: struct calculator { virtual int add( int, int ) = 0; }; You could implement an abstract base class and then implement 3 other classes (calculator_impl, calculator_client, calculator_server) such that your code is set up like so: struct calculator_impl : calculator { int add( int a, int b ) { return a + b; } }; struct calcualtor_client : calculator { int add( int a, int b ) { udp_socket->send( pack(a,b), server_endpoint ); return unpack_int( udp_sock->recv() ); } }; struct calcualtor_server { void udp_recv( packet ) { int sum = calc->add( unpack(packet) ); } udp_send(pack(sum)); } calculator_impl* calc; }; Any time you change your calculator interface you must now modify code in 4 places. It becomes a mess to maintain. Now lets take a closer look at calculator_client. Ideally you would like the client interface to be: struct calculator_client { future<int> add( int, int ); } Or suppose you and a more advanced protocol that supports different calling conventions (no return, scheduling, guarantees, retransmit attempts, etc). Now you want an interface like: struct calculator_client { struct add_ { future<int> operator(int,int); void invoke_without_return(int,int); }add; }; There is a well defined transformation between the abstract interface and the interface for the client and server. Now suppose you want to write some code that can deal with either calculator_client or calculator*. You are up a creak because there is no way to create an abstract base class for calculator_client and calculator because the calculator_client is implemented with function object member variables. So the goal and purpose of the IDL library is to describe an interface in such a way that it is easy to provide dynamic implementations/transformations of that interface and then deal with them all in a polymorphic manner.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"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. The first problem it could solve is the undefined implementation/ABI (of C++ virtual functions), which, for example, makes them useless when you want to release a closed source API that is naturally object-oriented and has/needs dynamic dispatching functionality _and_ that can be reliably used with different compilers without relying on alternative technologies like COM and CORBA. Boost.Interfaces could solve this by simply using a simple C struct of function pointers (of course as a low level private implementation detail, with a proper C++ wrapping) that provides a standard/defined ABI/layout... This would also allow for a policy to choose whether a particular interface will use the traditional 'static vtable + vtable_ptrs' approach or hold the vtable in the interface object itself (can be more efficient and/or flexible in some use cases)... It could decouple the concepts of dynamic dispatch and dynamic typing/RTTI...In the standard C++ version, when you add a virtual function to a class, you get both a function pointer (for dynamic dispatching) and a 'meta data record' (for dynamic typing/RTTI) which you might not want (for example if you do not need/use dynamic cast and do not want your internal implementation details visible, as clear text class and namespace names, in the produced binary and/or you do not want useles, uber long and uber mangled template-metaprograming-generated type names bloating your binary). Boost.Interfaces could simply provide a policy through which one specifies whether (s)he wants RTTI for a particular interface (what AFAICT it currently provides through the extract() member function template)... This would implicitly also provide a portable equivalent of the MSVC++ specific __decltype( novtable ) extension... A defined implementation would also be less rigid than the standard virtual function mechanism and allow some form(s) of runtime reflection, for example switching a function pointer of a bound interface to point/invoke a different implementation function... The decoupling of concept implementation, concept interface declaration and the binding of the two is also great. It allows for a much a cleaner way of doing what was otherwise one of the classic examples of policy based design, where you made a class configurable as to whether or not it used a virtual interface by adding a policy template parameter that was used as a base class... With a Boost.Interfaces-like approach the concrete, concept-implementing class would no longer need to be a template nor to inherit from an abstract interface class or define its own virtual functions...It would a matter of the users choice in a particular use case whether he/she will want to use dynamic-dispatched, type-erased interfaces or deal with concrete types directly...For example, I might have a large collection of concrete algorithm classes and in my own project I will use MPL typelists and compile time metaprogramming to deal with the different algorithms.. OTOH if I would want to release a closed source SDK with the same algorithms I'd use Boost.Interfaces to provide access to my algorithms without exposing the implementation... -- "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
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
"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
On Feb 11, 2011, at 11:08 AM, Domagoj Saric wrote:
"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...
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. 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. 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. This may be possible with C++0x veridic templates, but messy in C++03. Compile times are important to me.
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...
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. The best compromise may be to use Don Clugston's Fast Delegate which is simply 2 pointers per entry. The this pointer would be 'redundant', but it would probably greatly accelerate invocation speed and enable a natural syntax. Don's delegate probably uses too many 'hacks' to be considered for ABI simplification.
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...
I think the difference between the approaches is a matter of how easy it is to implement each method and how much boiler plate code we can eliminate for the user. The best code-it-by-hand solution is outlined in the boostcon 2010 presentation on type erasure (previously linked in this thread). The purpose of a library would be to reduce the amount of work required to achieve this.
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..?
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.
-- "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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"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
On Fri, Feb 11, 2011 at 11:03 PM, Daniel Larimer <dlarimer@gmail.com> wrote:
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.
The article's analysis is wrong. From the beginning Boost.Function used the "small object optimization" to avoid an "expensive heap memory allocation that [would be] required to store the member function and the bound object on which member function call is made" -- Dave Abrahams BoostPro Computing http://www.boostpro.com
"Daniel Larimer" <dlarimer@gmail.com> wrote in message news:8E36E262-2EFC-432C-B21C-CA204E663911@gmail.com...
I think the goal of the interface library should be a more flexible/powerful version of "boost::any" that allows you to define the interface of the object stored in the 'any'. In this way it takes type erasure to a new level. ...snip... 2) Provide the ability to define 'dynamic' implementations of an interface for calling RPC, scripting language interface, etc. 3) Objects that implement 'interfaces' should be long-lasting 'actors' where overhead of creating/copying/destroying the interface along with any memory usage is of secondary importance to the ease of defining dynamic interfaces and achieving 'type erasure'.
It seems you are making the typical mistake of fitting a (very) low level library/tool to your particular needs... In the use cases described in the post to Edward Diener I, for example, have no need for (2) and, as such, am not willing to pay for (3)... Additional power is always welcome when it is optional...otherwise it becomes 'inflexibility' and 'bloat'... -- "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
participants (6)
-
Daniel Larimer -
Dave Abrahams -
Domagoj Saric -
Edward Diener -
Joaquin M Lopez Munoz -
Vicente Botet