[vlc-devel] [vlc-commits] Remove libvlc_free
robux4 at ycbcr.xyz
Fri May 24 07:44:15 CEST 2019
On 2019-05-24 7:25, Steve Lhomme wrote:
> 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
>> 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.
Another use case: building libvlc/vlc with allocation tooling,
redirecting malloc/free to debug leaks. Calling free() outside of libvlc
with memory allocated this will likely crash or report errors when a
legitimate free() is done. We should not tie our hands by allowing
free() at all.
I also think we may differentiate between the types to free, like
libvlc_free_string(). But I think that's all we currently share to free.
> >Not only that but delete
>> would bring rather interesting considerations with RTTI.
>> If you want to abstract that away, you need case-specific release
>> 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
> 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
>> 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().
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
More information about the vlc-devel