[vlc-devel] commit: New C++ binding for libvlc. ( R?mi Duraffort )

[jpd at videolan.org]

On Mon, Jan 25, 2010 at 02:08:02PM +0100, Pierre d'Herbemont wrote:
> :) Using C++ features should be done lightly, so using C++ features is
> certainly not something you want to do.

Besides being circular reasoning, this makes exactly no sense to me.


> Don't tell me that you see selector dispatch (even more non virtual)
> in profile. It cannot convince me, unless you show me numbers.

Who said anything about what-do-you-mean-with-that-anyway?

I said to use the classes wrappers as thin and light as possible, so
inlining what amounts to one or two calls is called for, instead of
yet another cache trashing intermediary that adds no value. Even if it
doesn't directly impact performance it clearly makes no sense to add
yet another layer that can trivially be removed.

That, or do a true separation by going fully virtual so that the client
program does not need any includes beyond the C++ binding headers.

But don't go sit inbetween with lame excuses like the rest of the
thread. The recompiling/API changes argument is invalid exactly because
with including libvlc headers you have to recompile everything when
anything changes there anyway.

So either go as thin as possible and inline, or go virtual and do an
actual separation. That or convince me with arguments. These are not.


> > If you dislike wrapping libvlc in C++ classes that much there's no
> > point in having them at all. A better argument is called for.
> 
> libvlc was designed to be used with an Object oriented binding along.
> Using plain C libvlc is certainly not the most elegant stuff you have.

So?