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

Pierre d'Herbemont pdherbemont at free.fr
Mon Jan 25 14:08:02 CET 2010


On Mon, Jan 25, 2010 at 1:11 PM,  <jpd at videolan.org> wrote:
> On Mon, Jan 25, 2010 at 12:58:18PM +0100, Pierre d'Herbemont wrote:
>> On Jan 25, 2010, at 9:48, jpd at videolan.org wrote:
>> >You don't even need a set prefix, overloading will take care of it:
>> >
>> >mtime_t MediaPlayer::time();
>> >void MediaPlayer::time(mtime_t);
>>
>> Please dont.
>
> Why not? Why favour asymmetry?
>
> This is C++ after all, you know, might as well use its features.

:) Using C++ features should be done lightly, so using C++ features is
certainly not something you want to do. "And then we overload =". I
think that using the same method name should indicate the same class
of action. I agree that this might be a matter of taste, but the
general tendency is to do that, so this is why it should be preferred
also (See Qt, WebKit...).

>> >I also think that the wrapper classes should inline (much) more
>> >methods; now they're convenient but add entirely avoidable call
>> >overhead.
>>
>> I dont think it's actually a good idea. You save nothing, and makes
>> headers unreadable. And it makes API even more a PITA.
>
> Not true, and I disagree plus easily circumvented. And I disagree.

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

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

> Similarly, not throwing exceptions pretty much defeats the purpose of
> this particular C++ binding. If you'd rather not use exceptions, there
> is the libvlc C interface, trivially accessible from C++ already.

I have never say something against it. And I do agree as well :)

Pierre.



More information about the vlc-devel mailing list