From: Rob Stewart (stewart_at_[hidden])
Date: 2004-09-03 23:36:41
From: "Jonathan Turkanis" <technews_at_[hidden]>
> "Rob Stewart" <stewart_at_[hidden]> wrote in message:
> > From: "Jonathan Turkanis" <technews_at_[hidden]>
> > > "Rob Stewart" <stewart_at_[hidden]> wrote in message
> I'm sorry if I sounded argumentative in my last post.
I didn't notice.
> > > > There are plenty of places where one can misuse existing
> > > > libraries, including the Standard Library, so perhaps requiring
> > > > that protection from this library is misguided. So, here's
> > > > another approach: perhaps you could create a set of overloaded
> > > > make_* functions that take a varying number of filter arguments
> > > > followed by an optional (via overloading) resource argument.
> > > > Then, those functions can ensure that if there is a resource, it
> > > > is push()'d last.
> Did I misunderstand you the first time around -- you're not saying the arguments
> would be automatically reordered if a resource is in the middle, are you? It
> would just produce an error, right?
Yes. A given overload, with arity N, would require that only
argument N may be a resource.
> > > Yes, that would work. There are two versions I can think of:
> > >
> > > 1. Orginally I had a function link(...) which created an inline chain of
> > > and resources, but I eliminated it to make the library smaller. It didn't
> > > to me to add a compile-time check that the last element was a resource; in
> > > I thought it would also be useful for chaining filters alone. However, this
> > > might be a good reason to restore the function link, with the added check.
> > This is rather like using smart pointers. You can always call
> > new and delete, and work with raw pointers, but it's up to you to
> > guard against errors, including in the face of exceptions. When
> > using smart pointers, which are wrappers around raw pointers, you
> > gain safety.
> So link would just be a programmer-imposed check.
> > I think that what you have is fine, but that a safer means built
> > atop what exists is a better approach and can be added later as
> > time permits.
I didn't mean to say it would be a better approach. I meant it
would be safer.
-- Rob Stewart stewart_at_[hidden] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk