[pdal] Shared ptr madness
Michael P. Gerlek
mpg at flaxen.com
Wed Jul 13 23:12:08 EDT 2011
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
More information about the pdal
mailing list