From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17503 invoked by alias); 30 Jul 2003 15:27:09 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 17496 invoked from network); 30 Jul 2003 15:27:09 -0000 Received: from unknown (HELO ams006.ftl.affinity.com) (216.219.253.199) by sources.redhat.com with SMTP; 30 Jul 2003 15:27:09 -0000 Received: from coyotegulch.com ([68.200.44.160]) by ams.ftl.affinity.com with ESMTP id <218063-22772>; Wed, 30 Jul 2003 11:26:15 -0400 Message-ID: <3F27E392.2080504@coyotegulch.com> Date: Wed, 30 Jul 2003 15:45:00 -0000 From: Scott Robert Ladd User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030714 Debian/1.4-2 X-Accept-Language: en MIME-Version: 1.0 To: Richard.Earnshaw@arm.com CC: Gabriel Dos Reis , Alexandre Oliva , Richard Guenther , gcc@gcc.gnu.org Subject: Re: std::pow implementation References: <200307301037.h6UAb3P18424@pc960.cambridge.arm.com> In-Reply-To: <200307301037.h6UAb3P18424@pc960.cambridge.arm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-07/txt/msg02196.txt.bz2 Richard Earnshaw wrote: > This is talking specifically about *very small* functions ("one or two > assignments"). It says nothing about what happens if the programmer > decides to put a 2000 line monstrosity in the middle of a class definition > (which would be legal, if somewhat stupid). A practical compiler > eventually has to say "enough is enough", or it is likely to crash, run > out of memory or whatever. I do not want my freedom limited by the stupidity of others. If someone explicitly inlines a 2000-line function, let them; the wisdom of such a choice (or lack thereof) is an issue for code review and the marketplace. Let's say that I use a little shell sort in a program; should the compiler decide to replace my explicit choice of algorithm with quicksort, even though I have determined that shell sort is better? When I say "inline", I mean inline, regardless of other opinions (including those of the compiler). > I disagree. What really counts is that the compiler has sufficient > information to do a good job when compiling the code (ie to reduce, and > hopefully eliminate, the abstraction penalty). What constitutes a "good > job" is up to the compiler... No. What constitutes a "good job" is defined by a human mind, not a piece of technology that lacks any concept of "good." Over the years, I've found many arrogant tools (and not just from Microsoft) -- tools that assume, *incorrectly*, that their "wisdom" exceeds mine. -- Scott Robert Ladd Coyote Gulch Productions (http://www.coyotegulch.com) Software Invention for High-Performance Computing