On 03/10/10 10:05, Thorsten Behrens wrote:
* use of fundamental types like long and int.
Whereas I think the former is quite sensible (also the added
SAL_NO_VTABLE), I have some issues with the latter. Are there any
reasons _in favor_ of that, except for platform apis & the
occasional loop counter?
Yes: different semantics.
On the one hand:
The sal_Bool, sal_[u]Int{8,16,32,64}, and sal_Unicode typedefs were all
needed to provide types supporting the semantics required by the
corresponding UNO types, portably across various platforms and/or across
both C and C++.
The sal_Char typedef is pretty much useless. There is so much existing
code that combines sal_Char and C/C++ string literals which would break
if sal_Char were anything but plain char that sal_Char can just be
considered an historic artifact, identical to plain char. (And, for
simplicity, I personally prefer using the latter over the former most of
the time.)
The sal_{s,u}Char typedefs are probably (and hopefully) completely unused.
The sal_Size and sal_PtrDiff typedefs are pretty much useless. Their
semantics are obviously the same as C's size_t and ptrdiff_t (and thus
C++'s std::size_t and std::ptrdiff_t). However, they are implemented in
terms of sal_[u]Int{32,64}, instead of directly in terms of C's size_t
and ptrdiff_t, for reasons unclear to me. (And so, strictly speaking,
sal_{Size,PtrDiff} should not be mixed with [std::]{size,ptrdiff}_t. I
would suggest avoiding the former where possible.)
The sal_sSize typedef is an abstraction over POSIX's ssize_t and the
sal_[u]IntPtr typedefs are abstractions over C99's [u]intptr_t (though,
unfortunately, in both cases the former are not defined in terms of the
latter, where applicable).
On the other hand:
C++ bool is the type to use for boolean values. (And it should be clear
that sal_Bool would be a poor replacement for it.)
C++ int is the canonic type to use for integral quantities that are
obviously within the guaranteed range of that type. Absent any
additional constraints, why complicate things (and, potentially,
pessimize the generated code) with using, say, sal_Int32 instead?
C++ long is the canonic type for integral quantities that are unbounded
(i.e., code needs to take care of overflow to outside
LONG_MIN--LONG_MAX) but for which plain long is deemed more appropriate
than more complex, but more accurate solutions, like arbitrary-precision
big-integer classes. Absent any additional constraints, why complicate
things with using, say, sal_Int64 instead? (For C99, long long would be
the canonic type to use instead.)
As Frank already wrote, we would need to have concrete cases in the code
base to discuss what type(def)s are most appropriate there.
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
