<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 12 mars 2020 07 h 15, Carlos Rafael Giani <<a href="mailto:crg7475@mailbox.org">crg7475@mailbox.org</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On 11.03.20 21:57, Marcin Kolny wrote:<br>
> In terms of plugins; it's actually possible to write them fully in <br>
> C++. Unfortunately I never managed to write any example, but there's a <br>
> few tests which you can treat as examples [1].<br>
<br>
<br>
I've done that in the past. This is largely straightforward, but there <br>
are a few gotchas:<br>
<br>
<br>
1. Any C++ objects in the element and element class structures must be <br>
initialized with placement-new (don't forget to include the <new> header <br>
for this!) and have their destructors explicitely called. That's because <br>
the structures are allocated with C allocators, which know nothing about <br>
constructors and destructors. Example:<br>
<br>
struct MyGstElement<br>
{<br>
   GstElement parent;<br>
<br>
   MyCppObject cpp_object;<br>
};<br>
<br>
....<br>
<br>
void my_gst_element_init(MyGstElement *self)<br>
{<br>
   new (&self->cpp_object) MyCppObject(<constructor arguments>);<br>
}<br>
<br>
void my_gst_element_finalize(GObject *object)<br>
{<br>
   ...<br>
   self->cpp_object.~MyCppObject();<br>
   ...<br>
}<br>
<br>
Since this can get annoying quickly if you have many C++ objects in your <br>
element, I recommend creating one struct with all C++ objects inside, <br>
and then call that struct's constructor and destructor in _init() and <br>
_finalize().<br>
<br>
<br>
2. Surround GST_PLUGIN_DEFINE() with extern "C" { }. Otherwise, name <br>
mangling may mess up the symbols that the plugin loader looks for.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">This is already handled by that macro.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
3. Sometimes, people like to write internal structs and call the struct <br>
instances something like "private". But "private" is a C++ keyword!<br>
<br>
<br>
4. I recommend using std::string as often as you can instead of C <br>
strings, since the former are _so_ much nicer and easier to use. But <br>
when combining them with GObject properties, GstStructures etc. you must <br>
always remember to convert from/to C strings. Since the type is erased <br>
at compile time, nothing will warn you or produce an error, you can <br>
easily get a crash instead.<br>
<br>
<br>
5. C++ is more strict about implicit casts. In particular, in GParam <br>
functions like g_param_spec_uint(), the flags parameter is often set to <br>
a bitwise OR combination of enums, like G_PARAM_READWRITE | <br>
G_PARAM_STATIC_STRINGS . In C, this is implicitely cast to GParamFlags. <br>
In C++, you get a compiler error, so you must explicitely cast this, <br>
like so: GParamFlags(G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS)<br>
<br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank" rel="noreferrer">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</blockquote></div></div></div>