I want to add some math functions, include ceil, floor, sqrt, sin, cos, exp, fabs, etc. Functions must work similar to standard C function with same name, but with fixed point numbers. I think it would be useful for end user. This is not on your proposal. What would be the result type of these operations? Do you know efficient algorithms for these operations for fixed-point numbers? Do you think you will have enough time. Could you categorize the features of your library with MUST/SHOULD/COULD so that we have an idea of the priorities.
The trig functions are difficult to implement generically in my experience. Most of the fixed point implementations rely on lookup tables with CORDIC algorithms. The lookup tables would have to be calculated with metaprogramming when you allow for essentially arbitrary fixed-point layouts.
Vicente Botet wrote
Why the range and resolution must be static? Which advantages would have a run-time range and/or resolution? On which context each approach is preferable? I think run-time range and resolution more comfortable and useful, but require more resources.
Template meta-programming is not easy. Would you be more comfortable to implement a run-time solution before the static one?
This would certainly be a deal breaker for most (all?) embedded use cases.
User can create new variable and set any capacity. I think it is enough. IMO, a lot off the people interested in fixed-point numbers use them for embedded systems, and they are requesting a closed arithmetic (see other fixed-point threads on this ML) as no dynamic memory should be used by the fixed-point numbers, so the precision must be bounded. I don't think they will accept a fixed point library that don't allows them to work with closed arithmetic.
Yep that would include me and my use cases.