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

[jpd at videolan.org]

On Mon, Jan 25, 2010 at 03:14:51PM +0100, Pierre d'Herbemont wrote:
> On Mon, Jan 25, 2010 at 2:37 PM,  <jpd at videolan.org> wrote:
> > 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*.

I see no reason to add *easily preventable* overhead for the wrong
reasons. Make that a habit and it saves some searching for performance
when you really need it.


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

Fine, do that.


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

Inclusion is not a good idea because it defeats the "requires no
compilation on changes" argument brought up earlier. But if this is
desired anyway, then we might as well use the fact. Consequently we
might as well inline some completely superfluous calls and save a couple
of completely superfluous object files, and so on.

So either do it and do it well, or don't do it but do that well.


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

Then write the bindings such that for the client no other headers but
those for the bindings are used. And do that from right now on.
That would be fine.

But be sure to do it because it won't happen later.


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

Timed to happen before the 1.1 freeze. I understood that this was not a
problem, but breakage after initial release was.