Re: [boost] [wave) experiences

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2005-12-07 06:57:49

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