it is used to control the inline semantics.
By combining it with optimize option "-fno-inline"
for the internal M*LIB function (using _Pragma optimize)
we can control easily if we want to use an inline version
or call of an external function.
Define new user API:
* M_USE_EXTERN_DECL : define it before including any MLIB header to requests to call the M*LIB functions and don't inline then.
* M_USE_EXTERN_DEF : define it once in a translation unit to define the M*LIB functions. This translation unit shall contain all templated macro too.
If you use one option, you need to use the other one too for another translation unit.
from the container oplist.
It has no real practical purpose.
NEW/DEL/REALLOC/FREE shall be a property of the container
to be defined, and not a property for an already defined container.
As a consequence, the oplist arguments for TUPLE_OPLIST
are much more rigorous. It shall really be the real oplists
of the types used to create the tuple, otherwise a compilation
error may be generated.
if the method in the oplist uses API_* transformation,
if this method is a macro itself,
it may delay the expansion too much and
the macro may not be expanded at all in the final code generation.
Fix issue by adding a supplementary evaluation in the macro expansion.
Add test cases
a suffix ending with _ct means confidential type
ans is reserved for M*LIB internal usage.
OPLIST doesn't use the external types
but rather the internal types.
It enables to be independent of the real names
of the external types.
Such external names are planned to be fully customizable
(i.e. the user may define a name that suits its coding style)
This is to enable M_GLOBAL_OPLIST_OR_DEF to properly expand the erroneous oplist to the backend generator, that will report the error.
As such the erreneous oplist is surrounded by two pairs of brackets (())
Patrick Pelissier