Re: [boost] Formal Review Request: TypeErasure

Subject: Re: [boost] Formal Review Request: TypeErasure
From: Hite, Christopher (Christopher.Hite_at_[hidden])
Date: 2012-06-08 09:47:22

Dave Abrahams:
> Chris:
> > So the nice thing about the any vs. classic virtual functions is it is 
> > nonintrusive.

> Actually, that's only one of many nice things.  See Sean Parent's 2nd talk from C++Now!  Oh, the videos aren't posted yet.

> Well, the chain of implications, off the top of my head, goes like this:

> OOP => different sized objects being handled through the same interface
>     => dynamic allocation   (- complicated)
>     => memory management    (- hard)
> and => reference semantics  (- hard to reason about)
>     => shared state         (- hard to reason about)
>     => MT synchronization
>     => deadlocks, races, and inefficiency

> In a nutshell, concept-based-runtime-polymorphism/type-erasure allows you to have runtime polymorphism while preserving value semantics.  The value of that win is very commonly underestimated.

I think you're overselling it a bit here.  You can have value sematics with interfaces, just pass around these and heap all the time in clone and maintain single points of ownership or shared_ptr.  It has about the same cost as boost::function.

struct interface{
        virtual ~interface()=0;
        virtual interface* clone()=0;	
};

To be fair consider the version of any<..,_self&> which doesn't tackle storage and ownership and compare that with an interface with virtual functions.  With the any<...,_self&> I've got a virtual table pointer and a pointer to the type-deleted object.  With interface& I've got a pointer to an object with a virtual table intruding into it.

Assuming you've got a massive interface with tons of functions on it, it doesn't make sense to use any.  Another example, I often make shared objects (or DLLs) with a single factory function that gets me an interface.  This interface is generally pretty massive since it exposes everything in the library.  I don't think it would makes sense to have that factory function return an any, because it would have a complex ugly definition.  Also there's an issue with the definition of any changing whereas virtual table layouts won't change.

I notice the boost library never has massive interfaces.  Someone here might argue that you shouldn't have them in general.  I don't know.  I think asio works well with simple functors, though it seems a little forced that completion handlers take an error which can be no error.  In some cases you can break interfaces apart and into multiple pieces.
        subscribeConnected
        subscribeMessageRecieved
        subscribeDisconnected

Do you guys think it is just a question of style?

I'd have a really hard time envisioning something like DOM which is designed by interface (probably by java programmers), re-written with a bunch of any<> and functors.  Though I wouldn't say Xercies is prefect.

Most things in boost are nice light independent libraries; most things in industry are hugh modules with complex interfaces between them.  Maybe that's the difference.

Maybe I'm wrong and we can deprecate virtual functions from C++.

Chris