From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,1676be4fafed1dbb X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews1.google.com!not-for-mail From: aschwarz@acm.org (skidmarks) Newsgroups: comp.lang.ada Subject: Re: Semantics of Inline vs non-Inline Date: 15 Oct 2004 09:57:55 -0700 Organization: http://groups.google.com Message-ID: <35f054ea.0410150857.79165644@posting.google.com> References: <35f054ea.0410140733.5f250e6f@posting.google.com> NNTP-Posting-Host: 12.72.61.223 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1097859475 22242 127.0.0.1 (15 Oct 2004 16:57:55 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 15 Oct 2004 16:57:55 +0000 (UTC) Xref: g2news1.google.com comp.lang.ada:5255 Date: 2004-10-15T09:57:55-07:00 List-Id: Simon Wright wrote in message news:... > 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