[prev in list] [next in list] [prev in thread] [next in thread] 

List:       boost
Subject:    Re: [boost] GSOC 2013
From:       "Vicente J. Botet Escriba" <vicente.botet () wanadoo ! fr>
Date:       2013-04-25 6:27:55
Message-ID: 5178CCEB.6060200 () wanadoo ! fr
[Download RAW message or body]

Le 24/04/13 23:59, Dmitriy Gorbel a =E9crit :
> 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 structur=
e.
> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/bo=
ost
[prev in list] [next in list] [prev in thread] [next in thread]