Stephan Bergmann 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: > > [bunch of good examples snipped] > Hi Stephan,
sure, I buy those. Would then be worthwhile to re-def the types you listed in terms of their C/std:: counterparts. Can do that. sal_sChar is indeed unused, sal_uChar not so much (but there should be a trivial 1:1 mapping). Or better even, mass-move things like sal_Size/PtrDiff over to size_t etc. Let me get to the remainder: > 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? > I wince when I read "obviously" in this context. I grant you the pessimization argument, that's what I was alluding to with my loop counter example - but still, except for the most simple cases, these have a tendency to later spread their value's usage into surrounding code. Let's stick with the default choice of "use the sal_* types", unless there are more convincing arguments. > 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.) > I think that causes more harm than benefit, and many extra opportunities for subtle platform differences. Make up your mind what range you want to support, and then choose a sal type. Cheers, -- Thorsten
pgpSVlNTQFi0i.pgp
Description: PGP signature
