Boost logo

Boost :

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2005-12-07 04:10:17


> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]] 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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk