Re: [Cgdb-devel] C ADT library

[Ronald Landheer-C. <ro...@la...>]

Bob Rossi wrote:

>Hi,
>
>Well, CGDB is experiencing another round of development. With this, I
>and other developers have found that we can not continue to write CGDB
>without having some core ADT's that CGDB can rely on. This is
>inevitable.
>
>So, there are 3 choices that I can think of.
>1. Write a libadt ( from scratch )
>2. Use an existing library ( out of the box )
>3. Modify an existing library.
>
>I think that solution 1 is not a good solution. The goal of this project
>is not to write and test a new C ADT library, but to get a curses based
>debugger to GDB working :)
>
>I have searched the web for the last few days, and in my disgust, have
>come to find that there is not a single, widely used implementation, of a
>set of ADT's that can be used in C. So, I don't think option 2 is viable
>either. If someone can find a library this is good to use and is
>portable, please let me know.
>
>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 
>1. garray
>2. ghash 
>3. glist
>4. gqueue
>5. gtree
>6. gstring ?
>7. gcompletion?, 
>
>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.
>  
>
If you're looking for a widely-used already-existing C implementation of 
a set of ADTs (and only ADTs) that will run OOTB on every platform 
supported by GDB, I'm afraid you might be asking a bit too much. It is 
what libcontain aims to become (other than being "blindingly fast", 
thread-safe for all operations, etc.) but that is precisely because such 
a library - to my knowledge, doesn't exist yet.

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

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

That's my $0.02 :)

@+,

Ronald