[vlc-devel] [vlc-commits] Remove libvlc_free

[Steve Lhomme]

On 2019-05-23 17:11, Rémi Denis-Courmont wrote:
> Le torstaina 23. toukokuuta 2019, 13.57.32 EEST Steve Lhomme a écrit :
>> Here's another one: we could decide to rewrite libvlc in C++ and keep
>> the same ABI. Does that mean we would have to forced libvlc hosts to
>> call "delete psz-str" because we don't feel like keeping libvlc_free() ?
> 
> You would have to keep using malloc() otherwise you would break the existing
> ABI 3.0 or 4.0 anyway that says you can use free(). 

That's indeed a problem. I think the free() option should not have been 
there in the first place. I would rather vote to remove this option.

For example we could decide that for performance reasons we allocate 
using aligned_alloc(). On some system that requires an aligned_free(). 
We cannot do that if we allow free() of a particular runtime.

 >Not only that but delete
> would bring rather interesting considerations with RTTI.
> 
> If you want to abstract that away, you need case-specific release functions
> like Romain pointed out - not libvlc_free().

It turns out that in many cases it would not be libvlc_free().

>> That would force every host app to embed a C++ runtime just because
>> libvlc happens to be written in C++.
> 
> That example is absurd. In general, just switching LibVLC to C++ breaks the
> ABI. 

The extern "C" ABI remains the same, even if it's coded in C++ underneath.

 > Whether it requires the application to have a C++ runtime or not would
> depend on the platform. In many cases, it actually would indeed need a C++
> runtime regardless of libvlc_free().

Yes, running a C++ libvlc will require a C++ runtime. That doesn't mean 
the libvlc host has to deal with it. Again, in Windows this is hidden 
when loading the DLL (dunno how .so loading works). There is no reason 
to force the host to call the C++ delete. Just like there is no reason 
to force the host to call the C free().