Boost logo

Boost :

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

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:

  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

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at