Re: [boost] GSOC 2013

Subject: Re: [boost] GSOC 2013
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-04-25 02:27:55

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