Boost logo

Boost :

From: Jens Maurer (jmaurer_at_[hidden])
Date: 2000-02-18 16:48:57


Ed Brey wrote:
> It seems that it might be common for an application to want to know whether
> there is an interger of size x at compile time. Rather than just throw in
> the proposed macro into config.hpp, a better solution would be to provide
> some generic mechanism for programs to determine what types are available.
> This would be best put into stdint.h or cstding.hpp so as to provide
> existing practice. Ideas on how best to do this?

>From a practical point of view, we can assume that int8_t, int16_t and
int32_t are all available after including <boost/stdint.h>. The only
question is whether int64_t is there or not. We could probably find out
like this: sizeof(int32_t) == sizeof(intmax_t) => int64_t not available
otherwise: int64_t probably available.

However, wrapping this in some template specialization hackery really
doesn't cut it, because the name int64_t will be unknown anyway and
thus, the program using it (although in some non-instantiated template)
will not compile. I think we need some preprocessor logic for that, and
*please* a bit less polluting than #include <limits.h> and checking
ULONG_LONG_MAX for some magic value.
 
> > Btw, I've guarded "using std::xxx" declarations with
> > #ifndef BOOST_NO_STDC_NAMESPACE.
>
> As an alternative to sprinkling compiler workarounds throughout the code,
> you can take a page from config.hpp's book and put one workaround at the
> beginning of the header:

Thanks for the pointer to the documentation. [Done]

> Then use std::log in the code, as if you were living in a perfect world.

Not quite, I still have to use "using std::log" so that, if somebody
implements a new float-like type, Koenig lookup gets the correct
function, which will not necessarily live in namespace std.

> Additionally, I think that this would obviate the need for the gcc_hack
> code.

No, it doesn't. Unfortunately.

Jens Maurer.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk