Re: [boost] Problems with boost on Cray C++ release 3.6

From: John Maddock (jm_at_[hidden])
Date: 2003-01-18 06:55:12

> 1.) it seems that Cray C++ with the "-h conform" option, which enforces
> strict standard conformance does not compile this code in
> boost/filesystem/operations.hpp
>
> class directory_iterator
>        : public boost::iterator< std::input_iterator_tag,
>            path, std::ptrdiff_t, const path *, const path & >
>      {
>      public:
>        reference operator*() const { return m_deref(); }
> ...
>    };
>
> but complains that reference is not defined. My questions is whether
> this is a bug in the Cray C++ compiler, or whether the above code (and
> inheritance of the reference type from the base class) is actually not
> standard conforming. Can the standard experts help me with that?
>
> Anyways, this code can be made to compile by changing compiler options
> to be less standard-conforming.

I think it is a bug: member lookup rules (10.2) requires that base classes
are searched as well as the current class (this is not quite true for
template classes, but the class is not a template in this case).

One workaround might be to add:

typedef boost::iterator< std::input_iterator_tag, path, std::ptrdiff_t,
const path *, const path & > base_type;
typedef base_type::reference reference;

>
> 2.) The main problem, and one which breaks most boost libraries is that
> there is no <cstdint> header, nor stdint.h. Neither is required by the
> standard, so this is no bug on the Cray side. However, the boost
> workaround in boost/cstdint.hpp also fails:
>
> # if USHRT_MAX == 0xffff
>       typedef short           int16_t;
> ...
> # else
> #    error defaults not correct; you must hand modify boost/cstdint.hpp
> # endif
>
> because on the Cray vector systems a short is 32 bit, and there is no
> intrinsic 16-bit integer type. What shall we do?
>
> My suggestions is that we might need a BOOST_NO_INT16_T macro in
> addition to the BOOST_NO_INT64_T macro we have now, and to just define
> that macro in the code, instead of aborting with an error:
>
> # if USHRT_MAX == 0xffff
>       typedef short           int16_t;
> ...
> # else
> #define BOOST_NO_INT16_T
> # endif
>
> What do you think?

Probably we need to add a customised stdint.hpp for that compiler, or else
modify the checks to something like:

#ifdef __WHATEVER_CRAY_DEFINES__
     typedef short           int_least16_t;
     typedef unsigned short  uint_least16_t;
# elif USHRT_MAX == 0xffff
     typedef short           int16_t;
     typedef short           int_least16_t;
     typedef short           int_fast16_t;
     typedef unsigned short  uint16_t;
     typedef unsigned short  uint_least16_t;
     typedef unsigned short  uint_fast16_t;
# else
#    error defaults not correct; you must hand modify boost/cstdint.hpp
# endif

If you can test and supply patches they would be much appreciated, come to
that, I don't suppose you would like to volunteer to regularly run the
regression tests on that platform would you (no problem if you can't
though)?  Testing on Cray would be useful if only because the architecture
is so different from the usual 32-bit platforms we test on.

Thanks for the feedback,

John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/index.htm