"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