Boost logo

Boost :

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-06-02 16:42:25


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 02 June 2008 15:42 pm, Peter Dimov wrote:
> >
> > Oh, I came up with a reason that having future_value objects as inputs
> > can be
> > preferable to the solution you describe. Your solution forces the
> > "lifted"
> > functions to always take templates arguments. But template methods can't
> > be
> > made virtual. Also, you can't pass them to bind() without manually
> > specifying all the template parameters.
>
> Hm. I'm not sure I follow. Let's say that I have:
>
> struct A
> {
> virtual int f( long x ) = 0;
> };
>
> int g();
>
> future<int> h( A* pa )
> {
> return async( &A::f, pa, async( g ) );
> }
>
> What's the problem with the outer async recognizing that its third argument
> is a future and treating it as a dependency?

That's interesting, is this async stuff from an existing library somewhere, or
is it a hypothetical interface? I don't see any problem with it.
 
I was thinking of a virtual active object class, like:

struct ActiveA
{
        virtual future_value<int> f( future_value<long> x ) = 0;
};

I believe your solution could be used to achieve similar effects, but it is a
very different interface. I'm not saying my interface is the only way to
skin the cat, just that I want to be able to implement the interface I prefer
and make it work as well as possible.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIRFsx5vihyNWuA4URAtQ0AKDK/MKpUzFJuAUk/yUhxxUkuny3MQCfdBNu
KYeis+VWtWRuNzABJcqrbx8=
=NJKJ
-----END PGP SIGNATURE-----


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk