[vlc-devel] commit: New C++ binding for libvlc. ( R?mi Duraffort )
pdherbemont at free.fr
Mon Jan 25 15:14:51 CET 2010
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
> 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.
More information about the vlc-devel