This could simplify logics in the source. Now this test is done
like 'if (aStr.getLength() != 0) {...}' or 'if (!aStr.getLength()) {...}'.
With isEmpty() this looks like:
if (aStr.isEmpty()) {...}
if (!aStr.isEmpty()) {...}
I think this would make the code more readable.
Re-introduce the possibility to define CPPU_LEAK_STATIC_DATA. This
time use it to bypass just the assertions that check that the type
description counts really are zero at the end of the
TypeDescriptor_Init_Impl destructor.
Add more informative debugging printout of which counts are non-zero.
Define CPPU_LEAK_STATIC_DATA for x64 Windows for now. But we do get
the same assertions also on x86 Windows if cppu is built with
OSL_DEBUG_LEVEL>1.
We do print out a message if struct size verifications fail. That is
enough. No point in printing out the same
> sizeof(AlignSize_Impl) = 16
> sizeof(M) = 8
> sizeof(N) = 12
etc messages every time a cppu-using program is run and cppu has been
built for debugging.
I think I might actually be able to manage without any assembly coding
here, thanks to the clean design of the x64 Windows calling
convention, and tricking the compiler (in a fully documented and
stable way) by using varargs. uno2cpp.cxx might even be getting close
to working now, but cpp2uno.cxx and except.cxx parts are just forced
to compile by using dummy code.
Unfortunately the C++ name mangling in a 64-bit MSVC compilation is
slightly different from that in a 32-bit one:
-- An 'E' is inserted for pointers to indicate that they are 64
bits. I don't fully understand the rationale for this; isn't that the
only kind of pointer in 64-bit code produced by a C++ compiler anyway?
-- As there is only one calling convention on x64 Windows, __cdecl,
the indications for other calling conventions (here, especially
__thiscall) change to that for __cdecl.
It should be possible to write a tool to at least partially automate
conversion of 32-bit mangled names to 64-bit ones, and thus make it
easy to create mscx map files from the corresponding msci ones in
LibreOffice. Sure, it probably wouldn't work 100% correctly in all
cases, but it would help a lot.
Unfortunately the C++ name mangling in a 64-bit MSVC compilation is
slightly different from that in a 32-bit one:
-- An 'E' is inserted for pointers to indicate that they are 64
bits. I don't fully understand the rationale for this; isn't that the
only kind of pointer in 64-bit code produced by a C++ compiler anyway?
-- As there is only one calling convention on x64 Windows, __cdecl,
the indications for other calling conventions (here, especially
__thiscall) change to that for __cdecl.
It should be possible to write a tool to at least partially automate
conversion of 32-bit mangled names to 64-bit ones, and thus make it
easy to create mscx map files from the corresponding msci ones in
LibreOffice. Sure, it probably wouldn't work 100% correctly in all
cases, but it would help a lot.
