[pdal] Shared ptr madness

[Michael P. Gerlek]

We now have a factory that creates stages for us, e.g.

    boost::shared_ptr<Reader> ptr1 =
factory.createReader("drivers.las.reader", Options::none());

Observe that this returns a shared_ptr, which is probably the Right Thing To
Do.

Now consider the next line of code, where we create a filter using that
pointer to a reader we just got:

    boost::shared_ptr<Filter> ptr2 = factory.createFilter("filters.crop",
*ptr1, Options::none());

Observe that we are passing in to the filter "*ptr1" as the "previous stage"
parameter, because the ctor for a Filter takes a "const Stage&".  We need to
deref the shared_ptr to get the real ptr.


Question: should the filter stages take shared_ptr<Stage> parameters instead
of Stage& parameters?  It seems like if we don't pass in a shared ptr, we're
sort of mixing models -- if you are going to have a shared_ptr to something,
you should use that shared_ptr semantics everywhere.


Possible opposing view: actually the Filters take a const reference (const
Stage&), not a true pointer, so we need not use or worry about the
shared_ptr semantics.


Possible opposing opposing view: the MultiFilter class takes a N previous
stages as a parameter, typed as "const std::vector<const Stage*>".  Note
this is an actual pointer, not a reference, because you can't have a
std::vector of reference objects.  So now we have three different kinds of
pointers to a Stage (shared, real * ptr, and &-ref ptr) all being used,
unless we switch to "std::vector<shared_ptr<Stage>>".


-mpg