Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-02-04 18:55:58


At 05:06 PM 2/4/2003, Matthias Troyer wrote:

>I have run the regression tests on a Cray SV1 system using the Cray C++
>3.6 compiler and posted the results on
>http://www.comp-phys.org/boost/cs-sn9626.html

Thanks, Matthias, those are really interesting. I'm always curious how C++
in general and Boost in particular does on systems other than the usual
beige desktop boxes.

Why don't you consider posting the results on SourceForge with the other
results? It would be nice to use something that included "cray" rather than
"sn9626" in the file names, and we ought to tweak the config to better
identify the platform and compiler, but those are just nits.

>
>I have not looked at all the problems yet and will do so when I find
>time. For now I have posted it just in case that someone (such as a
>library author) is interested.
>
> One of the problems is that there is no int16_t type on the Cray SV1
>and other vector machines (with the exception of the newly announced X1
>on which int16_t exists but is very slow). Thus it might be good to add
>a BOOST_NO_INT16_T macro in analogy to the BOOST_NO_INT64_T macro.
>
>Another problem is that the type long long exists but is not supported
>by the standard library (e.g. the operator <<(std::ostream&, long long)
>is not defined). Since long and long long are both 64 bit there is
>actually no need to ever use long long. I'll have to check why long
>long is used in some of the tests.
>
>There are a few other places where I guess that there is a compiler
>problem, since I do believe that most of the boost code should be
>standard conforming. Any comments by the experts are welcome.

I took a look, and quite a few of the failures are tests that also have
trouble on other compilers. Hopefully some of these will pass in the next
week or two as we get ready for the release. There are probably have a few
configuration issues to be worked out, but really it isn't a bad showing
for a first try.

config_info is reporting the compiler as using the EDG front-end, but not
identifying the library. Whose copyrights are on the headers?

As far as the filesystem library goes, the two run errors detected are
really minor; the implementation seems to be reporting one error code
differently from other POSIX systems, and it is allowing remove on a
directory that is not empty. I can fix both of those problems if you can
tell me some macro name that uniquely identifies Cray C++ (because the same
problems aren't showing on other POSIX platforms.)

Thanks for sharing your results! Most of us will never see a Cray, let
alone test on one.

--Beman


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