Re: Semantics of Inline vs non-Inline

[aschwarz@acm.org (skidmarks)]

Simon Wright <simon@pushface.org> wrote in message news:<x7vpt3k34yp.fsf@smaug.pushface.org>...

> GNAT has occasionally told me that something couldn't be inlined
> because of some feature of my code, and I would expect at the least
> that this would happen here. (I suspect your code is much cut down, a
> simple test here shows no problem -- 3.16a1).

 (I love GNAT). I'm using gcc-3.3.3-3 with gnat included. And as for 
 you, it works. (I suspect some, maybe all, of my 'vendor's pique is
 because I had the temerity to include the GNAT generated .exe, .ali
 and .o files - the vendor said: "oh well").

 Actually, the simple test case is sufficient to illustrate the issues.
 The thing that sticks in my craw is that I cleverly design a List 
 Manager so that the management functions were separated from the 
 application and data specific operations. (Some) application specific
 behaviors were provided in a generic, and if insufficient, the application
 must provide others in the code. However, it is expected that the 
 expanded inline subprograms would generate no code. Instead, the 
 subprograms are developed to isolate areas of concern, a la Ada, but
 not effect performance. If the errant subprograms can not be inlined,
 there will be a performance hit. The design is sturdy and will be
 maintained. But the inclusion of multiple layers of subprogram calls
 effects performance. From my viewpoint, it is important to resolve
 this so that inline code can be used (others on this thread have
 provided 'clues' or workarounds which I will try).

 Bye the bye, I've spent last several years trying to get management
 buyin on the use of 'free' software. No buying. Statements that
 the company can always provide support are unavailing.

Thank you

art