This is the mail archive of the
mailing list for the GCC project.
Re: std::pow implementation
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: Martin Reinecke <martin at mpa-garching dot mpg dot de>
- Cc: gcc at gcc dot gnu dot org
- Date: 31 Jul 2003 11:29:47 +0200
- Subject: Re: std::pow implementation
- Organization: Integrable Solutions
- References: <3F28DD37.firstname.lastname@example.org>
Martin Reinecke <email@example.com> writes:
| Gabriel Dos Reis wrote:
| > It is tempting to make the analogy with "register", but you have to
| > acknowledge the fact that inlining strategy is not at the same level
| > of sophistication as register allocation. Therefore, any answer you
| > get for the question above is irrelevant to whether you should decide
| > whether your programmed inliner always knows better than the
| > programmer. Until then, please listen to the programmer. Don't
| > transmute "inline".
| Yes, you should listen to the programmer. But unless the programmer
| has a chance to express his intent _exactly_, there is no way to find
| out what he really meant. And he cannot do so in the discussed situation.
How to be sure there would not be another quibble about whether he
really wanted to express exactly his intent? something like
[C] do you inline mean inline?
[C] Are you sure you really mean inline?
[C] Did you mean the last answer?
That way lies infinite recursion with no way of getting started,
i.e. no productive work. We don't need complication to get decent
results. KCC didn't need a hierarchy of intent of inline before
producing much better code. When we will reach the level where the
compiler trusts the programmer, we could start worrying about what is
next. Like they say here, Paris is built in one day.
First, start trusting the programmer; when you're good at that job, you
would be able to handle subtile distinctions.