On 11/03/2010 17:54, bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote: > On Thu, 11 Mar 2010 17:26:12 +0100 > Herbert Duerr <[email protected]> wrote: > >> That was my point. The rule that got us the hardcoded WIN16-style >> code then is not IMHO is not a good guide for the future. If the >> timeless native types had been used it would have grown with the >> platform. > > And thus would be ABI incompatible whenever the native types "grows". > Naa, thats not better. This way we are, in theory, at least still free > to make a sal_Int16 an 32-Bit value, whenever _we_ like to(*). With a > native type, we are bound to whatever the platform deems appropriate.
presumably when the native type sizes change, the compiler runtime will be ABI incompatible anyway, so that is a non-issue. imho, fixed size types are mandatory only on I/O paths: network protocols, file formats, and such. note that due to remote UNO and bridges the UNO APIs effectively constitute a network protocol, which is why the C++ binding uses fixed size types. > BR, > > Bjoern > > (*) Unless there is code that is _relying_ on overflows -- but that > stuff breaks too with "native type growth". -- "In other words, the answer to the question 'what is a medium/large application?' is simply this: Any application that is so difficult to manage as a result of the proliferation of side-effects, that it often requires a committee of authoritarianism to approve a change that is almost certainly going to cause devastating consequences." -- Tony Morris --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
