On 4/29/2013 1:46 AM, Andrey Semashev wrote:
On Mon, Apr 29, 2013 at 10:41 AM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> wrote:
BTW, the choice of the names in the C++1y proposal was a source of conflicts (as always). In my prototype I used
fxp_uint and fxp_int fxp_ufract and fxp_fract (fxp_ufreal and fxp_real)
Now if you put these classes on a specific namespace for each notation the choice of the default can be deferred without a major impact on the plan.
namespace fixed_point { namespace q { }
namespace cxx1y {} // if the default is cxx1y notation (a better name is welcome, e.g. rr for range and resolution) using cxx1y::fxp_uint; using cxx1y::fxp_int; ... }
With this approach the user could be precise enough
fixed_point::q::fxp_fract<8,4>**;
we could also name the namespace for fixed points fxp and use
fxp::q::fract<8,4>; fxp::rr::uinteger<8,4>;
Please, no cryptic abbreviations (and especially one letter names).
I've always felt that if floating point numbers are called float then fixed point numbers should be called fixed. fixed<24,8> representing a signed 24.8 fixed-point would be my preferred naming convention. It could be an alias for signed_fixed<24,8> much like int is for signed int. Then naturally if you needed to support unsigned fixed point types you could use unsigned_fixed<24,8>. I could see an argument made for fixed<int32_t,4> specifying the storage type and the radix, in this case 28.4. This handles the signed vs unsigned naturally and doesn't allow you to have (in my view) strange types like 8.4 which seems to require an odd 12bit integer type. If you absolutely needed an 8.4 type then you need fixed-width integer support beyond that provided by <cstdint>. You could provide an implementation of integer<12> that is a 12 bit integer and then make fixed<integer<12>,4>. In my opinion this is another library outside the scope of a fixed-point library.