Re: [boost] GTL compile time vs. run time accessors

From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2008-05-02 19:00:14

Steven wrote:
>I haven't really looked at your library yet.  If there is a significant

>amount of
>code that can't easily be refactored to use compile time accessors, by 
>all means
>use runtime access.  
This is indeed the case.  Use of the isotropic types is pervasive
throughout.  They are the foundation that the rest of the library was
implemented in terms of.

>Note in my earlier message I only intended to claim 
>that
>algorithms that don't need to deal with dynamic variations of the
index, 
>should
>use compile time access.

It looks like enums are legal arguments to this type of compile time
parameter:

#include <iostream>
enum orientation_2d_enum {HORIZONTAL = 0, VERTICAL = 1 };

template <orientation_2d_enum orient>
void foo() {
        if(orient == HORIZONTAL) std::cout << "HORIZONTAL\n";
        else std::cout << "HORIZONTAL\n";}

int main() { foo<HORIZONTAL>();}

The above code works fine.  In the case that the value is an enum value
(which is actually quite frequent) I absolutely agree that it is better
to have it be compile time rather than runtime, because the enum can
enforce type safety.  I think providing both compile time and runtime
accessors is fine.  The runtime accessors can be implemented in terms of
the compile time ones in the cases where the type doesn't provide
indexing (such as a tuple based point.)  People wanting better
performance with the runtime accessor can specialize it where
appropriate.

>Have you measured the performance when adapting a struct like this:
>struct Point {
>    int x;
>    int y;
>};

Yes, when compiled with optimization it is identical to access the
struct members directly or through the accessors (and the extra wrapper
class from the original design as well.)  Please note: if you forget to
use the result of your computation, dead code removal leads to a
misleading result because the compiler is more successful in removing
dead code in the case where there is less to be removed, so take care
confirming my result.

Thank you for your thoughtful response, it was truly in the spirit of
your sig. line and inspired me to solve the problem I was having with
the type safety of compile time values, which was the only (substantive)
argument I had against them.  My isotropic constants are enum values to
allow the compiler to more successfully provide constant propagation in
its optimization of the code.  Therefore, it is easy for me to use these
enums as the parameters of compile time accessors and that integrates
nicely with the rest of the library and complements what is already
there.

I'll post a revised design proposal (code) presently.

Thanks again,
Luke