Re: [boost] Re: Re: Re: IOStreams formal review start

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
> filters
> > > and resources, but I eliminated it to make the library smaller. It didn't
> occur
> > > to me to add a compile-time check that the last element was a resource; in
> fact,
> > > 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.

Yes.

> > 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;