Re: [Boost-users] Integral type with no upper limit?

Subject: Re: [Boost-users] Integral type with no upper limit?
From: francesco biscani (bluescarni_at_[hidden])
Date: 2009-05-27 10:11:29

I would also be really interested in this. I use GMP and I am pretty
satisfied with it, but I think there are interesting things that could be
done, like:

- template-based constant-size operands whose size could be selected at
compile time. This would eliminate dynamic allocation of memory, which is
needless for certain use cases (i.e., I want a 256-bit integer behaving like
native ints, or a float with strictly 512-bit mantissa, etc..), and open up
room for further speed optimizations. With generic programming it may be
possible to share a big chunk of the implementation between constant-size
and variable-size types;

- header-only library: if used with small operands, GMP can suffer some
performance penalty related to function call overhead. Maybe it would be
possible to minimize it using aggressive inlining?

 F.

On Wed, May 27, 2009 at 6:18 AM, Scott McMurray <me22.ca+boost_at_[hidden]>wrote:

> 2009/5/26 Marshall Clow <marshall_at_[hidden]>:
> > At 1:00 AM +0200 5/27/09, Michiel Helvensteijn wrote:
> >>
> >> Perhaps Boost shouldn't reinvent the wheel? There's already an
> open-source
> >> arbitrary precision arithmetic library: http://gmplib.org/
> >
> > Which says:
> >        GMP is distributed under the GNU LGPL. This license makes the
> library
> > free to use, share, and improve, and allows you to pass on the result.
> The
> > license gives freedoms, but also sets firm restrictions on the use with
> > non-free programs.
> >
> > There are people using Boost for both free and non-free programs.
> > It's my understanding that we (Boost) want to continue to support all of
> > them.
> >
>
> Personally, I think Boost would be best served providing some sort of
> expression template wrapper into which different arbitrary-precision
> numbers could be plugged.
>
> That would mean far less work to get something usable, as it could use
> the GMP implementation initially.  Then a BSL version of the
> implementation could be developed incrementally, while non-floss users
> could license some implementation to use with the Boost interface.
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>