-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Joel de Guzman
Exactly. I remember writing such a class. I'll see if I can dig it up. Essentially, it is just a fixed array of N integers. It's quite easy to write one with just a pair of integers but it's equally straightforward to generalize that to N integers.
One thing that matters, BTW, is that the standard requires a specific width for all calculations--which definitely matters for bit shifting (which the preprocessor is required to do). IOW, fixed precision bit shifting, at the very least, is required. If a literal (or value for that matter) is too big for 'unsigned long' or 'long' in current C++ or 'unsigned long long' or 'long long' in C, it is undefined behavior. Supporting it 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. User's can then explicitly lie if they need to. IMHO, it is in the community's ultimate best interest for preprocessors and compilers to be as *un-permissive* as possible. Compiler permissiveness and language extensions are a huge barrior to portability. Wave should reject any translation unit that exhibits realistically detectable undefined behavior. If there is something that should be specified differently than it is in current C++ or C, that's a problem with the language (not the implementation) that should be handled by those responsible for defining the language--which is the respective standards committees, not implementors. Regards, Paul Mensonides