Subject: Re: [boost] [interfaces] Boost Interface Library (2004?)
From: Domagoj Saric (domagoj.saric_at_[hidden])
Date: 2011-02-11 07:32:51
"Edward Diener" <eldiener_at_[hidden]> wrote in message
> 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
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
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
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
-- "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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk