This simplifies forward source compatibility when new fields are
added to SEncParamExt - when new fields are added to SEncParamExt,
this method makes sure those fields are initialized to the
default value - otherwise all API users would have to manually check
SEncParamExt every time it is updated to make sure there's no new fields
that should be set to a nonzero value by default (e.g. like
bEnableFrameSkip).
Instead just duplicate the common fields. These fields had to
be duplicated for the C interface compatibility anyway - but
this way there is no risk to accidentally introduce an ABI
break since there is no need for the layout of SEncParamBase to
actually match the start of SEncParamExt.
MSVC only got stdbool.h in MSVC 2013; provide a manual typedef
for this compiler instead.
The C interface test makes sure that this doesn't break the ABI.
TRUE/FALSE has intentionally been left in use for the few
platform specific APIs that define these constants themselves
and expect them to be used, for consistency.
Add a struct that matches the C++ interface vtable.
This requires that the C++ interface methods are declared to use
the same calling convention as normal C functions, and that the
C struct exactly matches the layout and ordering of the C++
virtual table - MSVC seemed to reorder methods if there were
overloaded methods.
This is required to make the order in the C++ virtual table
consistent in MSVC - previously the overloaded methods were
ordered differently in the vtable compared to the interface
declaration.
These pragmas specified that structs should be packed in a way
different from the normal way defined by the current platform ABI.
Since these pragmas are in headers part of the public API, and the
pragmas are nonstandard, this is a portability and compatibility
hazard (all code calling the library need to have the same support
for the nonstandard pragma).
Additionally, accessing unaligned struct members (as produced by this
tight struct packing) can give reduced performance or even lead to
crashes on platforms that require strict alignment.
The only theoretical possible benefits of using the pragma are either
matching a certain struct layout defined in some other, fixed ABI
(but since this is an interface defined by this library itself, there's
no such prior binary interface that needs to be matched), or to reduce
the memory usage by packing the structs tighter (where the reduction
would be marginal at best).
