Boost logo

Boost :

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
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
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, gregod at, cpdaniel at, john at