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