[geos-devel] Inlines?

Paul Ramsey pramsey at cleverelephant.ca
Wed Aug 12 14:24:09 PDT 2020



> 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.




More information about the geos-devel mailing list