----Original Message---- From: Paul Mensonides [mailto:pmenso57@comcast.net] Sent: 07 December 2005 09:10 To: boost@lists.boost.org Subject: Re: [boost] [wave) experiences
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).
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.
-- Martin Bonner Martin.Bonner@Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434
-----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
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. Regards Hartmut
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
Joel de Guzman wrote:
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.
I agree with you on that it would be generally useful for Boost and that it should fall back to the intrinsic types whenever possible. But wouldn't such a thing restrict Wave to one precision only (in the end N will be a compile time constant). What I really would like to see is something runtime configurable. Or do you had in mind an integer<N>, where N is some possible maximum defined at compile time? Regards Hartmut
Hartmut Kaiser wrote:
Joel de Guzman wrote:
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.
I agree with you on that it would be generally useful for Boost and that it should fall back to the intrinsic types whenever possible. But wouldn't such a thing restrict Wave to one precision only (in the end N will be a compile time constant). What I really would like to see is something runtime configurable. Or do you had in mind an integer<N>, where N is some possible maximum defined at compile time?
Compile time or even runtime (if you have a couple of integer<N> around). It's just like having an int16, int32, int64, around. Only in this case, you are not tied to the limitations of the platform and you are guaranteed to have the the exact precision that you need. Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
participants (4)
-
Hartmut Kaiser -
Joel de Guzman -
Martin Bonner -
Paul Mensonides