<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>Dan</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Dec 7, 2018 at 12:08 PM Martin Davis <<a href="mailto:mtnclimb@gmail.com">mtnclimb@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">As a counter-argument, it might be better to use the typedef, based on the principle of encapsulating implementation decisions.  Usual reasons:<div><br></div><div>* Reduces comprehension complexity </div><div>* Makes implementation easier to change</div><div>* 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</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Dec 7, 2018 at 6:40 AM Daniel Baston <<a href="mailto:dbaston@gmail.com" target="_blank">dbaston@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>Dan</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 6, 2018 at 5:46 PM Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca" target="_blank">pramsey@cleverelephant.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr">std::unique_ptr<Geometry> ?</div><div dir="ltr"><br></div><div>We've got a mishmash in the code base, what should it be?</div><div>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. </div><div><br></div><div>The best code styleguide is a consistent code base, so deciding and then globally changing makes the most sense, IMO.</div><div><br></div><div>P.</div></div></div>
_______________________________________________<br>
geos-devel mailing list<br>
<a href="mailto:geos-devel@lists.osgeo.org" target="_blank">geos-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/geos-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/geos-devel</a></blockquote></div>
_______________________________________________<br>
geos-devel mailing list<br>
<a href="mailto:geos-devel@lists.osgeo.org" target="_blank">geos-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/geos-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/geos-devel</a></blockquote></div>
_______________________________________________<br>
geos-devel mailing list<br>
<a href="mailto:geos-devel@lists.osgeo.org" target="_blank">geos-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/geos-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/geos-devel</a></blockquote></div>