Re: [Cgdb-devel] C ADT library

[Bob R. <bo...@br...>]

On Thu, Mar 04, 2004 at 09:25:17PM +0100, Ronald Landheer-Cieslak wrote:
> Bob Rossi wrote:
>=20
> >Hi,
> >
> >I am leaning towards option 3. Glib is widely used and comes with a
> >testsuite. I found that CGDB could have support for these ADT's=20
> >1. garray
> >2. ghash=20
> >3. glist
> >4. gqueue
> >5. gtree
> >6. gstring ?
> >7. gcompletion?,=20
> >
> >These are 5-7 of the 49+ files that are delivered with glib. It would
> >take about 1 week to abstract these files out of Glib, and then CGDB
> >would have access to these ADT's. If we go down this route, we area also
> >left with another question. Should we update the files when Glib
> >changes? or should we check them in with different names and totally
> >diverge from Glib?
> >
> >I would appreciate a response, since I can not continue development on
> >CGDB until this issue is resolved.
> >=20
> >
> If you're looking for a widely-used already-existing C implementation of=
=20
> a set of ADTs (and only ADTs) that will run OOTB on every platform=20
> supported by GDB, I'm afraid you might be asking a bit too much. It is=20
> what libcontain aims to become (other than being "blindingly fast",=20
> thread-safe for all operations, etc.) but that is precisely because such=
=20
> a library - to my knowledge, doesn't exist yet.

Are you interested in starting libcontain with the data structures from
Glib? But changing the interface, typedef's, ... so that you can change
the implementation later to whatever you want.

I would be interested in porting away the code and committing them to
libcontain.

CGDB, could then merge libcontain into it every time some nice new
improvement came along.  That way, you would get a head start on the
data structures you need, and CGDB could use libcontain.=20

It could be a marvelous relationship :)

> My personal preferences and pet projects aside, glib seems to be a very=
=20
> good choice, provided it really is very portable. If you do choose to go=
=20
> that way, please just make sure that the parts of glib you choose are=20
> cleanly cut out of glib and that you don't get left with any instable=20
> code that would have worked if glib had been there. Other than that,=20
> *please* make sure you can revert back to the state before integration=20
> of glib code (e.g. by doing it on a branch first and letting us porters=
=20
> have a go at it before merging it into HEAD).

Ok, I will add the new ADT classes to a branch.

> As far as keeping up with glib is concerned - I wouldn't bother: be on=20
> the lookout for bugs that are found in their implementation, but don't=20
> bother taking on new features they might add - you probably won't need=20
> them anyway.

You are right.
I don't ever plan on keeping up with Glib after the port.=20

Thanks,
Bob Rossi