Boost logo

Boost :

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-05-16 10:13:09

Hash: SHA1

On Friday 16 May 2008 05:14 am, Johan Torp wrote:
> Frank Mori Hess wrote:
> > I've just noticed that neither Anthony's or Braddock's future libraries
> > seem
> > to support construction of a future directly from a value, like
> >
> > future<int> fut_int(5);
> >
> > Adding such a constructor gives support for implicit conversion of a
> > value of
> > type T to a future<T>. So a function which takes futures as arguments
> > can also seamlessly accept values:
> >
> > future<void> my_func(future<int> f1, future<int> f2);
> >
> > my_func(fut_int, 3);
> Adding an explicit constructor is one thing. Allowing implicit type
> conversions is more dangeous and needs to be thought through carefully.
> Could you make do with explicit constructing?
> my_func(fut_int, future<int>(3));

Can you come up with any specific examples of how implicitly constructing a
ready future from a value would be dangerous? It's not like implicity
constructing a shared_ptr from a raw pointer, which might cause the raw
pointer to be accidentally deleted. It's certainly less dangerous than going
the other direction (which has generated some controversy): implicit
conversion of a future to a value, which can block. Note, I'm not suggesting
adding support for direct assignment from the template type. I certainly
wouldn't make the poet::future constructor explicit and diminish useability
without a concrete reason for doing so.

- --
Version: GnuPG v1.4.6 (GNU/Linux)


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