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

[Pierre d'Herbemont]

On Mon, Jan 25, 2010 at 2:37 PM,  <jpd at videolan.org> wrote:
> 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

I don't think that's the goal unless you are very picky about micro
performance optimization *sigh*. If you want this to make sure we
don't introduce new bug, I say that the C++ bindings should be
autogenerated, like python bindings, hence there would be nearly no
maintenance.

> 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.

This is where I understand your point that you've failed to explain
before :) You want to leverage the fact that libvlc C headers get
included. Inclusion is actually a good idea to reduce maintenance
overhead. Using inline will probably reduce overhead even more. Tell
me if I still don't get your point.

I'll try to once again to clarify my point:
Including libvlc C headers doesn't seem to be what we want here. It's
ok for now to reduce maintenance overhead, but in the future C++
bindings will be auto-generated, and having inline there will not make
sense. Let's prepare the future now. Hope you'll get that.

We want to make sure we focus on API stability, I understand that it's
painful. (I have seen you recent API stability breakage because of
function renaming so I understand that you don't probably share the
same view than I here). I think you should probably reconsider what
I've been saying from an other perspective. It seems that you consider
this as "dummy", but that only highlight your misunderstandings.

Pierre.