|
Boost : |
From: Brock Peabody (brock.peabody_at_[hidden])
Date: 2003-08-06 18:31:41
> -----Original Message-----
> From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]]
> On Behalf Of E. Gladyshev
> Sent: Wednesday, August 06, 2003 5:08 PM
> To: Boost mailing list
> Subject: RE: [boost] GUI/GDI template library
>
>
> --- Brock Peabody <brock.peabody_at_[hidden]>
> wrote:
> > cycle or two of our recursive (I thought they called
> > it iterative?)
>
> They do call it iterative. However in the C++ world
> iteration is like enumeration while recursion is a
> process where typically the input for the next call is
> derived from the result of the current call. So I
> called it recursive design just for fun. :)
> Yes, it is iterative design. Thanks.
I was just joking around, I know what you meant :)
>
> >
> > (2) I'd say the library should be no less thread
> > safe than the
> > underlying API. Some APIs may be inherently
> > thread-unsafe (MFC for
> > instance).
>
> Does it mean that the library should be thread safe
> because an underlying API could be multi- threaded? I
> think there are two options.
I just meant that if the underlying library was unsafe there would
probably not be anything we could do about it.
> 1. The layer 1 must appear as one threaded API that
> has a message queue (ala win32). In other words all
> calls from layer 1 to a library object has to be done
> in the context of the thread that created the object
> (ala win32).
> 2. The layer 1 can call a library object in the
> context of an internal thread.
>
> What option do think is better? I think this issuse
> will have a significant impact on our design.
I think it would be too complicated to pass messages across thread
boundaries. Is that what you were talking about?
>
> > (3) Use function objects ala boost::function<>?
> Sorry, I meant. Do we need to be able to send
> messages at layer 1/2 (ala SendMessage/PostMessage)?
> I don't think we need it at all, everything could be a
> function call?
I agree. I like the function call syntax better. There may be API's
that aren't message based, in which case we would have to emulate it
somehow if we were to use them.
Brock
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk