Re: Bitsets

[Daniel Jacobowitz]

On Sun, Jun 08, 2003 at 12:03:58PM -0400, Daniel Berlin wrote:
> 
> On Sunday, June 8, 2003, at 02:57  AM, Zack Weinberg wrote:
> 
> >Michael Hayes <address@hidden> writes:
> >
> >>I have attached a new version of a bitset library for review.  The
> >>goal is to replace the sbitmap and bitmap routines used in GCC with a
> >>common interface that will support multiple bitset implementations.
> >>
> >>Now for a little bit of history.  I submitted an earlier version of
> >>this code for review well over a year ago.  Mark Mitchell reviewed it
> >>favourably but requested some changes to the function vectoring.  I
> >>resubmitted the changes, Mark was too busy, another reviewer had a
> >>look but dropped the ball.
> >
> >I believe that was me, and I want to apologize for dropping the
> >ball.  I always meant to come back to it but whenever I had a chance I
> >could never find the current version of the patch.  Now you've made it
> >clear what the current version is, I promise to look at this Monday
> >morning.
> >
> >>In the interim I have been to busy to push the issue but the
> >>routines were adopted for use in Bison where they have been
> >>ISO-fied.  The Bison folks are keen for the routines to be used in
> >>GCC to share the maintenance.
> >>
> >>I originally wrote the routines as an extension to libiberty but this
> >>still has a K+R C restriction.  So I've created a separate library,
> >>primarily for testing and benchmarking.  The code is based on the
> >>current version in the Bison CVS repository but I have made a number
> >>of performance improvements and have added another bitset
> >>implementation.  This is similar to GCC's sbitmaps but allows for a
> >>variable size.
> >
> >I don't see any reason why not to have a data-structures library,
> >separate from libiberty (which could then concentrate on its original
> >portability function) and requiring a C89 compiler.  But it would be
> >best to call it libdatastructures (or some abbreviation of that term)
> >rather than libbitset.
> 
> For the record, i agree with Zack here. I know DJ doesn't like to add 
> datastructures to libiberty anyway, and they probably account for all 
> the API problems between versions libiberty ever has.

Strongly agree.  We've put a couple of things there just because it was
an available place to put them - they have to stay, now, but maybe we
should copy them into the new library and use those copies instead?

At least hash tables and splay trees are affected, and I think Dan put
in a ternary tree also?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer