[geos-devel] GeometryPtr or ...
dbaston at gmail.com
Fri Dec 7 09:29:38 PST 2018
I don't see what it encapsulates, though...it's not as though a GeometryPtr
is appropriate for all cases where a pointer to a geometry is needed, and a
user can manipulate a GeometryPtr without knowledge of the underlying type.
A GeometryPtr is only suitable in a situation where a unique_ptr could be
used, and a user must understand this to correctly use a GeometryPtr. (They
would also need to refer to standard library documentation to understand
what methods are available to a GeometryPtr, and how they are to be used.)
I guess the typedef would allow us to switch to some other implementation
of a unique pointer without a user being aware, but given that unique_ptr
is now in the standard library it's hard to imagine a situation where that
Agree with Paul that consistency is probably the most important thing.
Crude grepping shows ~700 usages of unique_ptr, ~200 usages of
Geometry::Ptr, ~100 usages of GeometryPtr, but this misses unqualified uses
of "Ptr" within classes that inherit from Geometry.
On Fri, Dec 7, 2018 at 12:08 PM Martin Davis <mtnclimb at gmail.com> wrote:
> As a counter-argument, it might be better to use the typedef, based on the
> principle of encapsulating implementation decisions. Usual reasons:
> * Reduces comprehension complexity
> * Makes implementation easier to change
> * Indicates that this is an explicit design decision made in the library,
> rather than something decided by individual developers on a case-by-case
> On Fri, Dec 7, 2018 at 6:40 AM Daniel Baston <dbaston at gmail.com> wrote:
>> I'd agree; I find that typedefs like GeometryPtr generally obfuscate
>> things. Although one can guess, it's not immediately obvious if GeometryPtr
>> means Geometry*, unique_ptr<Geometry>, shared_ptr<Geometry>, or something
>> On Thu, Dec 6, 2018 at 5:46 PM Paul Ramsey <pramsey at cleverelephant.ca>
>>> std::unique_ptr<Geometry> ?
>>> We've got a mishmash in the code base, what should it be?
>>> As a learner arriving at the code base, std::unique_ptr<Geometry> would
>>> have been easier, since then the semantics of the thing are more
>>> immediately transparent then. After working with it for a while, that's
>>> less of an issue because I've internalized the fact that GeometryPtr is a
>>> std::unique_ptr, but still.
>>> The best code styleguide is a consistent code base, so deciding and then
>>> globally changing makes the most sense, IMO.
>>> geos-devel mailing list
>>> geos-devel at lists.osgeo.org
>> geos-devel mailing list
>> geos-devel at lists.osgeo.org
> geos-devel mailing list
> geos-devel at lists.osgeo.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the geos-devel