[geos-devel] GeometryPtr or ...
mtnclimb at gmail.com
Fri Dec 7 09:08:01 PST 2018
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the geos-devel