[geos-devel] GeometryPtr or ...

[Daniel Baston]

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
would happen.

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.

Dan

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
> basis
>
> 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
>> else.
>>
>> Dan
>>
>> On Thu, Dec 6, 2018 at 5:46 PM Paul Ramsey <pramsey at cleverelephant.ca>
>> wrote:
>>
>>> 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.
>>>
>>> P.
>>> _______________________________________________
>>> geos-devel mailing list
>>> geos-devel at lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/geos-devel
>>
>> _______________________________________________
>> geos-devel mailing list
>> geos-devel at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/geos-devel
>
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20181207/c1c0e03e/attachment.html>