[geos-devel] Inlining

[Mateusz Łoskot]

strk at refractions.net wrote:
> On Mon, Apr 10, 2006 at 11:05:26AM +0200, Mateusz Å?oskot wrote:
>>strk at refractions.net wrote:
>>
>>>The rational would be, for a default build, to
>>>have inlines used by core library, but non-inlined
>>
>>Why not to use compiler switches to achive this behaviour?
> 
> 
> Is there such a switch for all compilers ?
> Or should we make GCC a requirement ?

Yes, every good and modern compiler provide options to control inlining.
I'd say it's a must.

In example, Microsoft VC++ provides:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_.2f.ob.asp

(I have only GCC and VC++, so I can't check it in other compilers)

>>>functions to be available for clients.
>>>I dunno if there's any standard compiler switch for
>>>this, but we might reproduce it with the custom mechanism.
>>
>>I think it's much simplier to use compiler switches instead of custom
>>mechanism. Here are two that should provide this behaviour:
>>-fno-inline
>>-fno-default-inline
> 
> 
> It's surely simpler for developers, but we want a consistent
> behaviour for builders.

Makefiles should include those options by default for debug building.
Next, configure script should provide a possibility to turn it on/off.

> Note that I'm not happy with shipping the .inl and to require
> GEOS_INLINE to be defined... so I'm open to discussion.

I feel it. So, that's why I'm looking for native and life-saving solution.

>>>For example, we might have an inline.cpp file including
>>>all of the .inl files with GEOS_INLINE undefined.
>>>I haven't tested this yet, though.
>>
>>If I could comment this approach, I don't like it.
>>This will scatter code too much, what make maintenance harder.
>>It'll be hard to navigate, remember which class member is inlined and
>>which is not, etc.
> 
> 
> CLASS=geom/Coordinate
> vi -o source/$CLASS.cpp source/headers/geos/$CLASS.{h,inl}

IMHO, it's not a solution at all.

Cheers
-- 
Mateusz Łoskot
http://mateusz.loskot.net