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

[Matthias Troyer]

On Saturday, January 18, 2003, at 12:55 PM, John Maddock wrote:

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).

Thanks for pointing out the appropriate section of the standard. I agree with you will report it to Cray as a bug. The funny thing is that the compiler complains only if I turn on the option "-h conform", making it strictly standard-conforming.

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;

Yes, but shall we do that in all instances where this type of code is found in boost? I think it is better for now to just use the right combination of compiler options, to make the compiler swallow this. Of course if a similar problem is found with other compilers, we can do it this way.

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?

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

I will try to implement this. Probably we cannot do it Cray-dependent since Cray has too many systems (from Alpha-CPUs in the T3E to their new X1 vector-CPUs). A better idea might be:

#ifdef USHRT_MAX == 0xffffffff
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,

I'll do that over the weekend and try to see if some parts of boost will then compile

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.

I'll try to do it at least once to see which parts of boost we can use, and see how much CPU time this gobbles up. If it is not too much, I will talk to our sysadmins if they would allow me to do it about once a month. I don't think that testing more often would be possible, since already compiling only the filesystem library takes about 15 minutes.

best regards,

Matthias

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost