Hartmut Kaiser wrote:
To be honest I've done some experiments, also with a polygon with a compile-time number of vertices. Called it the template <size_t D> gon so a gon<3> for a triangle, etc. It disappointed me a bit because the compile-time area calculation routine which I drafted turned out to be slower than the runtime version...
Do you mean the version generated using a compile time area calculation turns out to be slower at runtime than the native runtime version? I don't understand how this might be possible. What are you trying to achieve at compile time?
In the post, the compile-time version unrolls the loop during compilation; it doesn't compute a result based on values specified in the source that are defined at compilation. Thus, the compile-time function could have a higher cost. It will almost certainly have a higher cost in a debug build since many compilers do not inline in that situation. I'd have to think recursive function calls are going to be much more expensive than a simple for loop. In release, it really depends on how well a compiler inlines. I haven't done extensive testing on any current compiler, but I know MSVC 6.0 optimized very well when __forceinline was used judiciously, but was quite a bit more hit-or-miss when relying on its inlining decisions. -- Noah No virus found in this outgoing message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.0/1342 - Release Date: 3/25/2008 10:26 AM