
<html><head></head><body>No. In general, 'extern "C"' won't suffice to preserve the ABI as a whole. It only ensures that the function uses the C calling convention and namespace.<br><br>If you run a LibVLC app with an STDC++ ABI that differs from that of dynamically linked VLC C++ plugins, it will crash even now on some platforms. The C++ runtime version is part of the ABI even if none of the function prototypes are C++.<br><br><div class="gmail_quote">Le 24 mai 2019 08:25:18 GMT+03:00, Steve Lhomme <robux4@ycbcr.xyz> a écrit :<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<pre class="k9mail">On 2019-05-23 17:11, Rémi Denis-Courmont wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Le torstaina 23. toukokuuta 2019, 13.57.32 EEST Steve Lhomme a écrit :<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">Here's another one: we could decide to rewrite libvlc in C++ and keep<br>the same ABI. Does that mean we would have to forced libvlc hosts to<br>call "delete psz-str" because we don't feel like keeping libvlc_free() ?<br></blockquote>You would have to keep using malloc() otherwise you would break the existing<br>ABI 3.0 or 4.0 anyway that says you can use free(). <br></blockquote><br>That's indeed a problem. I think the free() option should not have been <br>there in the first place. I would rather vote to remove this option.<br><br>For example we could decide that for performance reasons we allocate <br>using aligned_alloc(). On some system that requires an aligned_free(). <br>We cannot do that if we allow free() of a particular runtime.<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Not only that but delete<br> would bring rather interesting considerations with RTTI.<br> <br> If you want to abstract that away, you need case-specific release functions<br> like Romain pointed out - not libvlc_free().<br></blockquote><br>It turns out that in many cases it would not be libvlc_free().<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">That would force every host app to embed a C++ runtime just because<br>libvlc happens to be written in C++.<br></blockquote>That example is absurd. In general, just switching LibVLC to C++ breaks the<br>ABI. <br></blockquote><br>The extern "C" ABI remains the same, even if it's coded in C++ underneath.<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Whether it requires the application to have a C++ runtime or not would<br>depend on the platform. In many cases, it actually would indeed need a C++<br>runtime regardless of libvlc_free().<br></blockquote><br>Yes, running a C++ libvlc will require a C++ runtime. That doesn't mean <br>the libvlc host has to deal with it. Again, in Windows this is hidden <br>when loading the DLL (dunno how .so loading works). There is no reason <br>to force the host to call the C++ delete. Just like there is no reason <br>to force the host to call the C free().<hr>vlc-devel mailing list<br>To unsubscribe or modify your subscription options:<br><a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a></pre></blockquote></div><br>-- <br>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.</body></html>