|
Boost : |
From: Beman Dawes (beman_at_[hidden])
Date: 1999-07-28 19:39:17
At 01:27 PM 7/28/99 -0600, Greg Colvin wrote:
>> 2) #include <cstdint>, and supply a version (with names in
namespace
>> std) for systems which don't already have one. At least one
compiler
>> vendor is already doing this. Pros: Minimum future impact if C++
>> eventually standardizes <cstdint>. Cons: The C++ committee may
never
>> standardize <cstdint> or may standardize it in a way incompatible
>> with C. (These seem low probability, or even very low
probability,
>> events, IMO.)
>
>I'm not sure that on all systems you can make this work -- you
>may not be able to have a header without an extension, or you may
>not be able to put your own stuff on the system path.
Hum... This might be a problem in theory, but in practice are there
really any compilers out there that would prevent (2)? Anyone know
of a real-world compiler with either of these limitations?
>> 3) #include <boost/stdint.hpp>, and supply same. Names in
namespace
>> boost. Cons: If <cstdint> becomes either common or standardized,
>> Boost is out-of-step.
>
>So I assume you mean "boost/stdint.hpp".
I guess I don't understand the difference, other than "..." having a
fallback to <...> which doesn't seem an issue here.
> As long as this can be
>implemented in terms of <stdint.h> or <cstdint> then we aren't
>out of step.
Well, out of step in that we would be using namespace boost instead
of namespace std.
> ...
>
>I'd add option 7: A <boost/stdint.hpp> that puts the names in
>std, eventually to be just something like:
>
> #ifndef BOOST_STDINT_HPP
> #define BOOST_STDINT_HPP
> #include <cstdint>
> #endif
If it really turns out that (2) is impractical (or is just plain too
scary), then this would be a fallback. Then if <cstdint> gets added
to some future C++ standard, the using can just be changed to
#include <cstdint> during normal maintenance. No other user or
implementor code would have to change, and that is a very desirable
characteristic, IMO.
Thanks for the input,
--Beman
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk