From: "Jonathan Turkanis" <technews@kangaroologic.com>
"Rob Stewart" <stewart@sig.com> wrote in message:
From: "Jonathan Turkanis" <technews@kangaroologic.com>
"Rob Stewart" <stewart@sig.com> 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@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;