[boost] [task] 0.2.1 Doesn't compile on VC7.1 / older gcc

Subject: [boost] [task] 0.2.1 Doesn't compile on VC7.1 / older gcc
From: Chard (boost_at_[hidden])
Date: 2009-06-30 16:04:10

Hi Oli,

As documented, you're testing MS compilation with VC9.  We're currently tied 
to VC7.1 and as we use a threadpool heavily (Philipp Henkel's) I have a 
particular interest in seeing an 'official' boost threadpool.  So forgive me 
if I keep these coming ;-)

There is another VC7.1 compiler conformance issue:

static_pool now has the contained pool_base class.  The pool_base::submit 
method constructs a handle<>, however, this has the VC7.1 'friend access to 
contained class' problem.

The handle<> (non-default) constructor is private, granting friend access to 
static_pool, however, static_pool<>::pool_base requires access, and VC7.1 
barfs.

I couldn't figure out the friend syntax (that works) to add to class 
handle<>, so for now I'm working with handle<> (hacked as) public.
(Note: earlier versions of gcc, e.g. 3.4.4, will exhibit this problem, too.)

I thought this would've been the syntax:

#  if BOOST_WORKAROUND(BOOST_MSVC, <= 1300)
  template <typename Channel>
  friend class static_pool<Channel>::pool_base;
#  endif

  but it doesn't appear to be legal.  Is this type of declaration even 
possible?

An alternative would be to move (some or all of) the functionality to the 
outer static_pool class, and route the inner pool_base class to it, e.g.

  template< typename R >
  handle< R > static_pool::pool_base::submit( boost::detail::thread_move_t< 
task< R > > t_)
  {
    static_pool::submit(*this, _t);
  }

  template< typename R >
  static handle< R> static_pool::submit(pool_base &pb_, 
boost::detail::thread_move_t< task< R > > t_)
  {
    ...
  }

Or, perhaps just the handle creation line.  However, it may be tidier just 
to have a detail::create_handle (that is the handle<> friend), seeing as you 
are just trying to say nobody else should be constructing a handle.

Regards, and keep up the good work...