Hi Grady, > On Mar 27, 2018, at 3:05 PM, grady player <derfoo...@icloud.com> wrote: > > So I haven't looked in great detail so this may all be info that you know, > and maybe not helpful... > > 1. You can easily link C objects to C++ code by marking it `extern "C"` > 2. You can not easily link C++ objects to C code, because there are classes, > vtables, name mangling etc. > 3. The solution for this interop is usually a shim layer that is compiled in > C++ and has a C interface, and is imported as extern "C" so the names aren't > mangled. > 4. there are 2 common headers for decklink, one that can contain C++ symbols > and one that contains only C symbols ( `IDeckLink` is a c++ class and can't > be included C Code)
Right. My goal was to confirm the purpose of the two structs really was entirely about the issues related to referencing C++ stuff from within C. > > So I don't know how you would really combine everything... you could keep the > all of the DeckLink classes in the decklink_cctx as (void *) but that isn't > elegant. Ugh, no. That is definitely not what I want to do. See below. > The only thing that seems useful would be de-duplication of the duplicate > fields and if those are only for state to be read on opening, then I dont > know that is exactly useful either, > but you could make an options struct and keep one ref to it in both contexts, > they are similar but slightly different... To be clear, I’m not saying that the two structs should be combined into one. What I’m proposing is refactoring to eliminate any duplicate members between the two, and move everything that isn’t C++ into the decklink_cctx, so that the *only* things that are specified in decklink_ctx are the C++ members. That eliminates any ambiguity about which struct should be used. For the most part, I’m just trying to understand if the members were duplicated intentionally across both structs for some good reason that isn’t obvious, or if it was just an oversight or misunderstanding as to the role of the two structs. Regards, Devin _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
