Boost logo

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
>> std) for systems which don't already have one. At least one
>> vendor is already doing this. Pros: Minimum future impact if C++
>> eventually standardizes <cstdint>. Cons: The C++ committee may
>> standardize <cstdint> or may standardize it in a way incompatible
>> with C. (These seem low probability, or even very low
>> 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
>> 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:
> #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,


Boost list run by bdawes at, gregod at, cpdaniel at, john at