|
Boost : |
From: Joel de Guzman (joel_at_[hidden])
Date: 2005-12-07 09:21:28
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk