|
Boost : |
From: Mac Murrett (mmurrett_at_[hidden])
Date: 2001-11-12 22:55:36
I would also like a version of this for implementing remote calls for the
Mac OS version of Boost.Thread. As the blue task (the one running Mac OS)
is the only task that can call most of the OS, remote calls can be quite
common, so speed is an issue. Furthermore, I would like to implement a
choice for memory management using remote calls, and so whatever mechanism I
use cannot allocate memory.
I will assist on this if it will help. I have created similar, albeit less
graceful, things like this in the past (for the exact same purpose).
Thanks,
Mac.
On 11/12/01 10:38 PM, "David Abrahams" <david.abrahams_at_[hidden]> wrote:
> Hi,
>
> For most applications, one wouldn't care that the constructor of
> boost::function<> might throw an exception. In my case, however, I need to
> ensure that it won't. I think I understand why dynamic allocation is
> neccessary to boost::function, but I think there's a wide class of
> applications for which it shouldn't be neccessary. I'm thinking of
> operations which need to use a function object, but don't need to store it
> (think for example of a suite of algorithms operating on a particular type
> of iterator).
>
> How far is boost::function from being able to provide this sort of
> functionality?
>
> Thanks,
> Dave
>
> ===================================================
> David Abrahams, C++ library designer for hire
> resume: http://users.rcn.com/abrahams/resume.html
>
> C++ Booster (http://www.boost.org)
> email: david.abrahams_at_[hidden]
> ===================================================
>
>
>
> Info: http://www.boost.org Unsubscribe:
> <mailto:boost-unsubscribe_at_[hidden]>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk