With the API rework/cleanup for 2.0, it has become more apparent that a lof of the classes we define in KaxSemantic are just the base integer/string class with a semantic context attached.
Rather than creating these classes, we could just use the base types instead, just exporting the semantic of the element to identify would is what. Only a few classes (not found in KaxSemantic) would actually need to have proper C++ classes because they have extra methods.
These semantic are currently constexpr in KaxSemantics.cpp. We may be able to put these constexpr in KaxSemantics.h, eliminating the need to even export them from the DLL.
While this is true for libmatroska, this can also be done with all the elements in the EBML header in libebml.
With the API rework/cleanup for 2.0, it has become more apparent that a lof of the classes we define in KaxSemantic are just the base integer/string class with a semantic context attached.
Rather than creating these classes, we could just use the base types instead, just exporting the semantic of the element to identify would is what. Only a few classes (not found in KaxSemantic) would actually need to have proper C++ classes because they have extra methods.
These semantic are currently constexpr in KaxSemantics.cpp. We may be able to put these constexpr in KaxSemantics.h, eliminating the need to even export them from the DLL.
While this is true for libmatroska, this can also be done with all the elements in the EBML header in libebml.