[v3] tr2: bool_set, dynamic_bitset, ratio

[v3] tr2: bool_set, dynamic_bitset, ratio

[Benjamin Kosnik]

[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]


Hi Edward! 

I have reviewed and selectively merged your development
branch, libstdcxx-tr2-ideas-branch, into trunk. As ISO C++ is now
looking at new library efforts for TR2 (and N2965 has already been
checked in to trunk) I thought it well-timed.

Please check my work, patch attached. 

On  libstdcxx-tr2-ideas-branch, I found:

1) N1718 + extensions for polynomial. 
2) N2136 bool_set
3) N2050 dynamic_bitset
4) ratio extensions for binary
5) cmath extensions
6) C++0x rope

Of these, I selected 2, 3, and 4 for merging.

It is sad to leave N1718 unmerged, I think there is a lot of good work
here and frankly see N1744 (marked with open status for LWG) as a weaker
candidate. But it's hard for me to justify putting this in given that it
was explicitly rejected by LWG. Perhaps you have current status or
thoughts?

For the rope extensions, I would suggest just adding C++0x bits to
ext/rope, instead of making tr2/rope. 

The <cmath> additions look interesting but I just saw declarations and
no actual implementation so I punted.

I would encourage you to continue working on TR2 projects! This
future work can now proceed on mainline, without a special branch.

tested x86_64/linux

-benjamin







[-- Attachment #2: 20111019-1.patch.bz2 --]
[-- Type: application/x-bzip, Size: 14505 bytes --]

Re: [v3] tr2: bool_set, dynamic_bitset, ratio

[Ed Smith-Rowland]

On 10/19/2011 06:48 PM, Benjamin Kosnik wrote:
> Hi Edward!
>
> I have reviewed and selectively merged your development
> branch, libstdcxx-tr2-ideas-branch, into trunk. As ISO C++ is now
> looking at new library efforts for TR2 (and N2965 has already been
> checked in to trunk) I thought it well-timed.
>
> Please check my work, patch attached.
>
> On  libstdcxx-tr2-ideas-branch, I found:
>
> 1) N1718 + extensions for polynomial.
> 2) N2136 bool_set
> 3) N2050 dynamic_bitset
> 4) ratio extensions for binary
> 5) cmath extensions
> 6) C++0x rope
>
> Of these, I selected 2, 3, and 4 for merging.
>
> It is sad to leave N1718 unmerged, I think there is a lot of good work
> here and frankly see N1744 (marked with open status for LWG) as a weaker
> candidate. But it's hard for me to justify putting this in given that it
> was explicitly rejected by LWG. Perhaps you have current status or
> thoughts?
>
> For the rope extensions, I would suggest just adding C++0x bits to
> ext/rope, instead of making tr2/rope.
>
> The<cmath>  additions look interesting but I just saw declarations and
> no actual implementation so I punted.
>
> I would encourage you to continue working on TR2 projects! This
> future work can now proceed on mainline, without a special branch.
>
> tested x86_64/linux
>
> -benjamin
>
>
>
>
>
>

Wow!  Thank you for putting these in!  I was going to take a look at 
these during 4.8 but this is a nice surprise!

The ones I'd most like to look at are real and integer.  Stroustrup and 
others have often expressed a wish for multiprecision maths in the 
library wish list.  I don't know if there is a paper yet.  I also did 
rational using the gmp library.  I'm wondering if rational should be a 
template class that could take any integral type - of which integer 
could be one - like boost rational.  I think I like that solution 
better.  I was also debating if we should make these multiprecision 
classes allocator aware.  I tend to think so.

Anyway, I'll take a look at the tr2 stuff that you checked in.  I hadn't 
considered constexpr, nullptr, noexcept because they weren't in place in 
g++ when I did all this.

Also, with <ratio> and typelist we might be able to get <units> pretty 
easily (although I haven't looked at it).  That would be really cool.

Thanks,
Ed

Re: [v3] tr2: bool_set, dynamic_bitset, ratio

[Joseph S. Myers]

On Wed, 19 Oct 2011, Ed Smith-Rowland wrote:

> I don't know if there is a paper yet.  I also did rational using the gmp
> library.  I'm wondering if rational should be a template class that could take

Having things in libstdc++ etc. using GMP runs into the same issues as 
libquadmath of not wanting to link in non-libc LGPL code unless required - 
in particular for -static-libstdc++, where you should be able to 
distribute a binary built with -static-libstdc++ without either it having 
a dependency on GMP (unless the relevant features are used) or including 
GMP code with the consequent complications to distribution requirements.  
(Quite apart from GMP changing its SONAME - not under our control, unlike 
libquadmath.)

-- 
Joseph S. Myers
joseph@codesourcery.com