There are a couple of classes in libcef_wrapper which are implemented in C++ and are only accessible by consuming the libcef_dll_wrapper library. I'd like to be able to provide some of these utilities in a companion library to CEF.swift but, as the C++ interop is nonexistent in Swift, I'd need a C API for that (or I'd have to reimplement everything but that's out of scope).
I set out to implement a bridge that closely mimics how the CEF C API is bridged to C++ using the CefCToCpp and CefCppToC adapters. I created a C interface for e.g. CefMessageRouterRendererSide and a corresponding CefMessageRouterRendererSideCppToC implementation. There were however 2 issues that I had to fix:
1. I had to manually add a new WT_MESSAGE_ROUTER_RENDERER_SIDE value in wrapper_types.h
2. there is a mismatch between base::RefCountedThreadSafe (base of CefMessageRouterRendererSide) and CefBaseRefCounted (expected by CefCppToCRefCounted) as the Release() in the former is void while in the latter returns a bool. This caused template instatiation problems in CefCppToCRefCounted which I rigged by making UnderlyingRelease() void (return value was not used anyway).
Now, with these hacks in place the code compiles. I could go ahead and patch each CEF release as it comes out, but I think these changes could as well be applied to the main codebase. Namely:
1. adding a CefWrapperType value for any potentially bridgeable utility class
2. making CefCppToCRefCounted::UnderlyingRelease() void by discarding the return value from the Release() of the wrapped struct (as I said, the result of UnderlyingRelease() is not used anywhere).
This would make it possible to write C++ => C bridges for the mentioned classes. What do you think? If you agree with the general direction, I can submit a PR.