Yes, maybe global state is not a cool design for GLM, and sure this feature would be different from what is currently done in the library.
If you don’t like the idea of such a “setup” function, what about implementing it as an extension ? It could be disabled by default it you really do not like it, in setup.hpp ^^
I see two possibilities for precomputation :
- having a setup function, which precalculates as many values as we ask it to precalculate
- having a static array in a header file, containing the values, as is done for example for the data of the teapot in FreeGLUT. The problem is that we could not choose the precision we want at runtime, and the executable would be bigger, because it would contain the data itself.
Personally, I would go for the 1st option ^^
About Boost, a debate on it could last longly ^^
Basically, what I do not like in it is :
- installation of it is awful, and not at all standardized (bjam and others…)
- each “component” of Boost has a HUGE dependency on other components of Boost
- it clearly slows down compilation
- its intrinsics are very hard to understand. This is a problem when using template-based components (like Boost.Python for example), where compiler errors are really undecipherable. This is also a problem when debugging, for example when the code uses Boost.Bind…
Boost wants to enhance C++ itself ; to my mind, if we want to add features to the language, we had better change the language itself. For this purpose, I like the D language, but it is still not mature for me (2 different standard libraries and const-ness sucks in D 1.0).