-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Martin Bonner
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. There is a reason why there is both implementation defined behavior and undefined behavior. For the former, pick a behavior and document it. For the latter, reject the translation unit if it is reasonable to detect it (meaning you don't have to bend over backward to detect it). Implementation defined behavior used by a client is the client's portability problem. Undefined behavior used by a client is the implementation's portability problem.
IMHO, it is in the community's ultimate best interest for preprocessors and compilers to be as *un-permissive* as possible.
... but in general I agree with this idea.
Regards, Paul Mensonides