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

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

Hello Chard, I do currently a rework/refactoring of the code - I'll take your points into account. I'll try to get test it with gcc3.4.4. best regrds, Oliver Am Dienstag 30 Juni 2009 22:04:10 schrieb Chard:
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...
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (2)
-
Chard
-
k-oli@gmx.de