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 <dbas...@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 <pram...@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@lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/geos-devel > > _______________________________________________ > geos-devel mailing list > geos-devel@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/geos-devel
_______________________________________________ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
