gcc-3.1 boost-1.28.0 problem

gcc-3.1 boost-1.28.0 problem

[Neal D. Becker]

A new error appears with boost-1.28.0 + gcc-3.1 that did not appear
with gcc-3.0.4.  I don't know if this code is actually valid or not.
It looks like this:


template<class UniformRandomNumberGenerator, int k, 
  class IntType = typename UniformRandomNumberGenerator::result_type,
...
class shuffle_output
{
public:
  typedef UniformRandomNumberGenerator base_type;
  typedef typename base_type::result_type result_type;
...
  friend std::ostream& operator<<(std::ostream& os, const shuffle_output& s)
  {
    os << s._rng << " " << s.y << " ";
>>>    std::copy(s.v, s.v+k, std::ostream_iterator<result_type>(os, " "));
    return os;
  }

The problem is this:

/usr/local/src/boost/boost/random/mersenne_twister.hpp: In function 
   `std::ostream& boost::random::operator<<(std::ostream&, const 
   boost::random::mersenne_twister<DataType, n, m, r, a, u, s, b, t, c, l, 
   val>&)':
/usr/local/src/boost/boost/random/shuffle_output.hpp:85: parse error before `;' 
   token

This is the line marked with ">>>" above.  I'm guessing that gcc
doesn't like result_type, because the friend function has no access to
the typedef.  Is this code OK or not?

Re: gcc-3.1 boost-1.28.0 problem

[Paolo Carlini]

Neal D. Becker wrote:

>A new error appears with boost-1.28.0 + gcc-3.1 that did not appear
>with gcc-3.0.4.  I don't know if this code is actually valid or not.
>It looks like this:
>  
>
Hi.

Can you possibly provide some additional information on how to reproduce 
the problem?

For, the relevant boost1.28 testsuite tests (random_test.cpp and 
random_demo.cpp) pass for me on x86-linux; indeed the testsuite is 
overall ok, with no regressions wrt gcc3.0.4.

Ciao,
Paolo.

Re: gcc-3.1 boost-1.28.0 problem

[Neal D. Becker]

We have a patch for the problem.  My diagnosis of the problem was
incorrect.  The problem was that you need to add

#include <iterator>

to both mersenne_twister.hpp and shuffle_output.hpp or you don't get
the definition for std::ostream_iterator.

But this brings up another gcc bug!  I had proposed a completely bogus
fix for the problem, which gcc-3.1 happily accepted!

What I had suggested is to change shuffle_output.hpp to say:

  friend std::ostream& operator<<(std::ostream& os, const shuffle_output& s)
  {
    os << s._rng << " " << s.y << " ";
    std::copy(s.v, s.v+k, std::ostream_iterator<s.result_type>(os, " "));
    return os;
  }

This is nonsense, as you can't refer to a type using ".", but gcc
doesn't complain at all.  Stranger still, it also doesn't complain
about the still undefined std::ostream_iterator.

If it is needed I can try to put together a simple test case.  Right
now all I have is a large program which I can't post.