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

Subject: Re: [boost] [task] 0.2.1 Doesn't compile on VC7.1 / older gcc
From: k-oli_at_[hidden]
Date: 2009-07-02 00:51:45

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