I believe that boost mandates implicit conversion to built-in types
*without* a conversion-wrapper. This means that if the user selects to lose performance by mixing, say, double with fixed_point, then the user did it---willingly, that is on purpose!
I'm seen the alternatives. How the user will use the library is explicit conversion is needed each time there is a lost of range or resolution.
It is clear that coding with this rule and mixing builtins is cumbersome. I could admit that mixin builtins could be take as some kind of implicit conversion and
It is a lot of coding. It was previously, in fact, my preference to require explicit construction and disallow and implicit mixing of the specialized number type with built-in types. But I later learned that boost.math follows the other strategy. This is the only reason why I keep mentioning this point, because of compatibility with boost.math and a potential boost.multiprecision.
About converting from one mantissa/fraction representation to another, I say don't ever do it without explicit ctor call or assignment operator. If you don't do this, then the code amount blows up beyond what it reasonably should.
Well, it should or not. I think that it should work only if A * A -> A You can never please all of the people all of the time. But my preference is exclusively supporting the closed world. I personally do not like it if results grow-to-size. There will certainly be varying opinions on this.
I think that we have two kind of fixed-point arithmetic * open A * A -> 2A * close A * A -> A It just scares me to think of all the coding you will need. Explicit ctor conversion from one size fixed-point to another and assignment operator should be enough. And you can keep the code amount down. But, again, there will be different opinions on this in the community.
Each one of these arithmetic should be supported by different class families. We could use the same name in different namespaces. Users using only one of this families will not see the naming difference just adding a using declaration. Do you really want to put yourself through this kind of pain?
Do you expect this to work in the closed fixed point-world fixed_point<4, -14> result2 = pi_rep<2, -8>() * pi_rep<2, -6>(); I do. Others might not.
After all I posted, perhaps a simple summary of my thoughts might help. Basically, I recommend the following: * Do support implicit conversion from built-in types (compatibility with strategy of boost.math). * Do not support result resizing or mixed fixed-point *intelligence*. * Do support explicit conversion of mixed fixed-point but *only* via explicit ctor and copy-assign.If you take a moment to consider these top-level design choices, you will find that they, in general, lead to the simplest code and reduce the sources of error for both author and users alike. I finally adopted this strategy with my *third* formal fixed-point class. But again, one person alone can never be right and many experienced developers will have other opinions and, eventually, find the right mix in cooperation. Thanks, Vicente. Best regards, Chris.