Hartmut Kaiser wrote:
Paul Mensonides wrote:
Supporting [extended length integers] is not a good idea. IMO, it is just the beginning of non-standard extensions. For the purpose of cross-compiling, I don't have a
problem with an
option to specify the width.
But what about cross compiling from a 32-bit platform for a 64-bit target? (which strikes me as a perfectly reasonable thing to do today).
It is reasonable. I'm not against being able to explicitly set the width with some sort of option--as long as it is explicit. What I'm basically saying is that once the option is set, the preprocessor should do everything at exactly that width (*as if* the width was the widest supported integral type for the platform--which is required by the standard) and reject anything that requires more. If the width isn't the width of the actual target, then the user is lying--which gives them an explicit way-out hack if absolutely necessary.
That was exactly, what I had in mind.
I suggest an integer<N> class that uses built-ins when it's detected that the compiler/platform supports N bits and switch to an emulated fixed precision integer of N bits when it is not available as a built-in. I also suggest that such a class would be generally useful in boost. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net