Tor Lillqvist
e1c6f36d8b
If the inpt matches one of the constants exactly, the result is the
name of that constant. If the input matches some combination of
constant values that are single bits, the result is the sequence of
the names of those constants joined with plus signs.
For instance, if the IDL has:
constants Constants {
const byte BIT0 = 1;
const byte BIT1 = 2;
const byte BIT2 = 4;
const byte BIT3 = 8;
}
The result of Constants::to_string(5) is "BIT0+BIT2", and the result
of Constants::to_string(17) is "17".
I am sure there are corner cases that aren't handled as would be
intuitive, especially with types that include unsigned values.
Correspondingly, the semantics of the generated to_string() functions
is not formally defined.
Also add a unit test for the new functionality.
Change-Id: I14aa826d0989ac6dfe97dd5c09119b1601c65643
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148995
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Language Code Generators for UNOIDL Entities
Generators for language-binding--specific representations of UNOIDL entities:
cppumakergenerates header (.hdland.hpp) files for the C++ UNO language bindingjavamakergenerates class files for the JVM language binding- the codemaker for .NET is in module
cli_ure
Some of the code is re-used by the skeletonmakers in module unodevtools.
Note the different terminology used by cppumaker vs. gbuild for the three variants that can be generated by cppumaker for some of the inline functions:
cppumaker switch: -L; cpputype.cxx: light; gbuild: normal;
cppumaker switch: none; cpputype.cxx: normal; gbuild: bootstrap;
cppumaker switch: -C; cpputype.cxx: comprehensive; gbuild: comprehensive;
which can be a source of confusion.