Le 24/04/13 23:59, Dmitriy Gorbel a écrit :
Michael, thanks for the links. As for me, this page also has interesting info(and this page give me idea to provide math functions). http://www.codeproject.com/Articles/37636/Fixed-Point-Class
Vicente Botet wrote
As I said there are several notations and there is no real one that would make happy everyone. So I think that the library should take in account this point and provide some aliases (c++11)/type traits(c++98) for the most common notations.
Choosing the default notation is critical and having a consensus on it would be difficult. Do you think that it is worth proposing several default notations and request the boost community to choose the default one? Yes, of course, boost community should choose the default notation. I would start this as soon as possible as this could take some time. I would start a thread as well for the naming of the different classes. Having to provide several notations let me think that the use of at least a namespace fixed_point is mandatory to don't pollute the Boost namespace.
What is the best way to provide several notations? Template alias?
That is less important issue, but I have question about the file structure. In the prototype all code in one file. But I think file structure may look like this: fixed_point.hpp - top level header fixed_point/cardinal.hpp fixed_point/integral.hpp fixed_point/nonnegative.hpp fixed_point/negatable.hpp fixed_point/functions.hpp fixed_point/common.hpp fixed_point/config.hpp
I do not insist, but I think segregation better than one file, and want to know your opinion. I have no problem with that for a final library and even I encourage you to do it to minimize dependencies if this helps. Please don't use /common.hpp file that has no meaning. Name your files depending on whatever they provide. Move any implementation detail file to fixed_point.hpp. When doing a prototype IMO it is better to put all in one file so that it can be shared easily. P.S. The proposal. proposal_Dmitriy_Gorbel.pdf http://boost.2283326.n4.nabble.com/file/n4646027/proposal_Dmitriy_Gorbel.pdf I think this is final version, or close to final.
As you are for using enum for rounding/overflow policies, could you add the policies that you must implement and when these policies will be implemented? I don't see when you would develop the math functions on the planning. Please don't forget to apply to GSoC as soon as possible so that the Mentors starts to evaluate your proposal and how you react to possible improvements. Best, Vicente