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

From: Matthias Troyer (troyer_at_[hidden])
Date: 2003-01-18 07:53:54

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