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: dewar at gnat dot com (Robert Dewar)
- Cc: Richard dot Earnshaw at arm dot com, coyote at coyotegulch dot com, aoliva at redhat dot com, gcc at gcc dot gnu dot org, kgardas at objectsecurity dot com, rguenth at tat dot physik dot uni-tuebingen dot de
- Date: 30 Jul 2003 18:28:21 +0200
- Subject: Re: std::pow implementation
- Organization: Integrable Solutions
- References: <20030730160945.5C81AF2E03@nile.gnat.com>
email@example.com (Robert Dewar) writes:
| The reason for not taking this view of inlining is that unless you
| get in the mindset that inlining will be done routinely by the
| compiler (at your direction) then you will tend to shy away from the
| use of trivial abstraction functions because you will worry about efficiency.
In effect, I find that it is the view that the C++ compiler always knows
better than the programmer that creates that sort of situation.
Should I use this compiler? No! It does not listen to the
Will the compiler inline this simple function? I'm not sure, it just
keeps on doing what he thinks is best for me. Uncertainty.
Should I program in C++ and use this compiler? Maybe not, some C++
compilers are notorously known not to inline inline function. Doubt.
| The quote about premature optimization here is wrong I think. What Knuth
| was talking about (go back and look at what he really said, not just the
| sound bite) was distorting the code prematurely and unnecessarily in the
| interests of optimization.
| In fact, the liberal use of inline tends to *prevent* premature optimization
That might be true for Ada, I'm doubteful it translates to C++ word-for-word.