[geos-devel] GeometryPtr or ...

[Martin Davis]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20181207/b3adc360/attachment.html>