[geos-devel] Inlines?

[Andrew Bell]

Unless you're dealing with templates or some functions that are important
to let the compiler inline so that it can "see" more code, I would just put
things in the .cpp file. Functions like accessors that are used frequently
should definitely be made available for inlining.

On Wed, Aug 12, 2020, 5:54 PM Paul Ramsey <pramsey at cleverelephant.ca> wrote:

>
>
> > On Aug 12, 2020, at 2:52 AM, Sandro Santilli <strk at kbt.io> wrote:
> >
> > On Tue, Aug 11, 2020 at 03:06:00PM -0700, Paul Ramsey wrote:
> >> Can anyone shed some light on our inlining strategy? It seems really...
> odd.
> >> Like picked at random, in ConvexHull, the following methods are inlined
> if GEOS_INLINE is on (it is by default).
> >>
> >> ConvexHull::ConvexHull(const geom::Geometry* newGeometry)
> >> ConvexHull::~ConvexHull()
> >> ConvexHull::extractCoordinates(const geom::Geometry* geom)
> >>
> >> Now... none of these feel like they are particularly hot path to me.
> The constructor, destructor, and a private utilty method.
> >> I ask mostly because there's a lot of this .inl stuff scattered around
> and it doesn't seem particularly helpful.
> >> If there's some history I'd be intrigued to know.
> >
> > I can't remember why those things ended up in .inl.
> > I guess destructors were there to try at debugging some issues
> > with virtual tables not being correct when destructors were inlined
> > (so to turn inlining off)
>
> Going back to an old question from mloskot, would it be crazy to just put
> the inlined functions into the standard header, marked "inline" and use
> compiler flags to turn off inling if we so desire? Maybe things work better
> now than they did ~2007 when you laid this structure out?
>
> P.
>
>
> _______________________________________________
> 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/20200812/7d037ea2/attachment.html>