Re: [boost] [interfaces] Boost Interface Library (2004?)

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 
news:iinlb5$thr$1_at_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