Is anyone actually using gstreamermm?

[David Ing]

Marcin --

I watched your presentation and it was excellent.

Do you know if anyone is planning to convert the gstreamermm project to
meson?  I am specifically interested in a solution where the Windows (MSVC)
build is simply supported by the same code generation / build scripts which
currently support the Linux build.  (My C++ code runs on both platforms.)

On Thu, Mar 12, 2020 at 5:10 AM Nicolas Dufresne <nicolas at ndufresne.ca>
wrote:

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