[vlc-devel] [vlc-commits] picture: socialize the reference counter
epirat07 at gmail.com
Wed Dec 12 18:49:12 CET 2018
On 12 Dec 2018, at 17:53, Rémi Denis-Courmont wrote:
> Le keskiviikkona 12. joulukuuta 2018, 11.10.41 EET Steve Lhomme a
> écrit :
>> On 11/12/2018 18:11, Rémi Denis-Courmont wrote:
>>> vlc | branch: master | Rémi Denis-Courmont <remi at remlab.net> | Mon
>>> Dec 10
>>> 23:29:55 2018 +0200| [fc809b3a06b06b9cad485bd6e830e9c11df93b7b] |
>>> committer: Rémi Denis-Courmont
>>> picture: socialize the reference counter
>>> include/vlc_picture.h | 8 ++++++++
>>> src/misc/picture.c | 7 +++----
>>> src/misc/picture.h | 1 -
>>> 3 files changed, 11 insertions(+), 5 deletions(-)
>>> diff --git a/include/vlc_picture.h b/include/vlc_picture.h
>>> index 2216e7072f..772bc4fc1d 100644
>>> --- a/include/vlc_picture.h
>>> +++ b/include/vlc_picture.h
>>> @@ -27,6 +27,12 @@
>>> #define VLC_PICTURE_H 1
>>> #include <assert.h>
>>> +#ifndef __cplusplus
>>> +#include <stdatomic.h>
>>> +#include <atomic>
>>> +using std::atomic_uintptr_t;
>> Is this safe for Objective-C to use these types created in C or C++ ?
>> (apparently they are interoperable between C and C++).
> That sounds like it depends on the toolchain, and I simply do not care
> Objective C(++).
> For the 15 years that I have been in this project, the policy has
> always been
> that native code is written in C unless necessary otherwise. And so we
> - SIMD in assembler,
> - C++ library dependent modules in C++,
> - heavily C++ template-dependent blender in C++,
> - etc.
> And if you introduce another language, you are responsibility for
> ensuring its
> interoperability with C. Pragmatically, few, if anybody, master all
> languages in VLC. I definitely do not. And so it cannot be expected
> that core
> maintainers will go out of their way to fix non-C or non-portable
Objective-C is an "extension" of C, everything you can do in C, you can
in Objective-C too.
So there is probably no need to care for Objective-C at all, as far as
code is concerned.
> Some people have violated the policy by using C++ for no approved
> Others have skirted it by writing nominally external C++ libraries
> with VLC
> integration in mind. That is frankly not nice as it unnecessarily
> who can maintain the code, even if it nominally follows the policy.
> I have introduced ARM A32 assembler on ELF by necessity, and I stick
> to my
> ensuing responsibilities. I do not recall introducing any other native
> language and so I refuse to take responsibility for any such.
> Rémi Denis-Courmont
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
More information about the vlc-devel