C++ Bindings

[Richard Eyre]

• How do I reference the C++ bindings in my Unit Tests so I am able to make use of them? 
  
• Also, should we be including the tests, and bindings in the visual studio project? Maybe underneath a separate 'tests' project?
  

[Caitlin Potter]

1. we need to link with libwebvttxx as well as libwebvtt, so adding $(top_builddir)/src/libwebvttxx/libwebvttxx-static.la to the LIBS variable in test/unit/Makefile.am will link to the C++ bindings. Following that however, you still need to subclass WebVTT::FileParser to make it deal with cues and errors the way you want it to, EG by making it count a number of cues or store it somewhere, or something. (This will probably not work right, actually, since the cues are not being reference counted properly yet iirc)
2. I'm not sure about the visual studio stuff. I think we'll probably have something to automatically generate a project that runs all the tests, however I'm not sure.

[Richard Eyre]

1. So other then linking the linking the C++ bindings within the Makefile.am there is nothing else needed to work with the bindings? 
   
2. Just out of curiosity, why is there no extension on the bindings like .c ? Since they do look like .c files.
   
3. The WebVTT::FileParser would be another binding? This would take care of reading the file?
4. What is left to do in these bindings. Can you give me a list of what you think we need to get this going?

[Caitlin Potter]

The C++ header files don't have an extension, the source files do (this is an old C++ convention, eg the STL has things like "#include <map>" or "#include <string>"

The WebVTT::FileParser is an abstract class, (partially) implemented in libwebvttxx. You still need to implement the virtual functions for it, so we'll probably want some shared sources used by all the tests implementing subclasses of FileParser.

Things left to do in the bindings: adding proper reference counting to the cue object, so that we don't delete a cue inappropriately, would be useful. It should be as simple as adding struct webvtt_refcount_t refs; to the webvtt_cue_t structure, and modifying the constructor to initialize it with a reference count of '1', and modifying webvtt_delete_cue to only actually delete if the derefenced refcount is equal to 0 (And probably rename delete_cue to release_cue), and implement a function to add a reference.

The problem with that is, being C code, the 'refs' member would be public and modifiable by anyone, so it could be abused potentially. Alternatively, it could be hidden in some way, but I don't really like that option much for other reasons. Besides that, reference counting in C is really painful and nobody should ever have to do that :( (If we had a more COM-style model, it could be workable, but it's kind of ill-advised, from a portability standpoint)

There's nothing in the C++ bindings yet for dealing with cue text, so that's another thing on the TODO list there.

[Richard Eyre]

I like the idea of reference counting the cues. If it could be used against us I guess that's just something that we will have to take care of at a later date.

I'd like to add the count of the number of cues somewhere as well, that would be nice. I don't think we are handling that anywhere right now. 

Now that I'm looking at this more I think I have an idea of where we need to head for the C++ bindings.

Has anyone else made any progress on this that we are aware of?

[Richard Eyre]

Should we be unit testing create and delete functions?

Am I able to use #defines that are in the C files directly in the C++ test code?

[Caitlin Potter]

The C++ code can see anything that's in the C headers (it depends on the C headers being available)

However, care must be taken when using the C++ headers, EG if libwebvttxx was compiled expecting a static link to libwebvtt, then you must static link with libwebvtt. And if it was compiled expecting a dynamic libwebvtt, then we have to link with a shared library build of libwebvtt (And need to define WEBVTT_STATIC or not, depending)

So, since it hasn't really been tested yet, it's not sure if it will work or not, but I hope to get it working now-ish.

[Richard Eyre]

Okay, sounds good.

It seems like we only have bindings for public functions so far. Shouldn't we be testing internal functions as well?