C Containers library

[jacob navia]

The project is going forward slowly but surely. I am trying to fix the
bugs in the standard implementation, improve the specs, eliminate
inconsistencies fo the definitions/interface of different containers, etc.

The doc is no longer written in Word/Open Office, whatever. I have
changed to latex (pdflatex) and the looks have improved a lot.

The libraries compile under Macintosh (64 bits), Windows 7 (64 and 32
bits) and linux (64 and 32 bits)

 

[Keith Thompson]

The project is going forward slowly but surely. I am trying to fix the
bugs in the standard implementation, improve the specs, eliminate
inconsistencies fo the definitions/interface of different containers, etc.

The doc is no longer written in Word/Open Office, whatever. I have
changed to latex (pdflatex) and the looks have improved a lot.

The libraries compile under Macintosh (64 bits), Windows 7 (64 and 32
bits) and linux (64 and 32 bits)

Is there a URL? You may have posted it before, but it would be good to
repeat it if you're going to start a new thread.

 

[Francois Grieu]

Is there a URL?

<http://www.cs.virginia.edu/~lcc-win32/container.html>

The info on that page is not quite up to date, but this is:
<http://www.cs.virginia.edu/~lcc-win32/container-lib-src.zip>

Francois Grieu

 

[James]

The project is going forward slowly but surely. I am trying to fix the
bugs in the standard implementation, improve the specs, eliminate
inconsistencies fo the definitions/interface of different containers, etc.

The doc is no longer written in Word/Open Office, whatever. I have changed
to latex (pdflatex) and the looks have improved a lot.

The libraries compile under Macintosh (64 bits), Windows 7 (64 and 32
bits) and linux (64 and 32 bits)

BLOAT_ware_extreme!


=^(

 

[Dann Corbit]

BLOAT_ware_extreme!


=^(

Why don't you show us how it's done properly.

 

[BGB / cr88192]

I don't know about James, but I do think that his container library can be
useful. Although, I can definitely see how his implementation of a
single-linked-list can be observed as "overkill". Personally, if I were
creating a robust container library, I think I would create several levels
of abstraction. Maybe something like:


1. super simple and highly efficient intrusive base implementation.

2. a higher level non-intrusive implementation based on `1'.

3. an even higher level implementation that allows for different objects
to be stored in the same list, again based on `1'.

4. perhaps another higher level that allows for custom allocators and
serialization, probably based on `3'.


AFAICT, using his single linked list as-is seems to be overkill.



Perhaps I am just totally missing something obvious here, but, why am I
forced to use vtables and all of that "baggage" just to create a _SIMPLE_
singly linked list?

can't say for Mr. Navia...

in my case, I have the (possibly even more overkill) option of using dynamic
types and cons cells for doing lists...

so, for example:
dyt x,y,z,c,t; //dyt=magic dynamically-typed reference
dyt lst;

....

lst=dylist3(x, y, z); //new list of 3 items.
note:
lst=dycons(x, dycons(y, dycons(z, NULL))); //equivalent

c=lst;
while(dyconsp(c))
{
t=dycar(c); //get the current item
//do something with t
c=dycdr(c); //go to next item...
}

 

[jacob navia]

Le 09/09/10 04:47, Chris M. Thomasson a écrit :

I don't know about James, but I do think that his container library can be
useful. Although, I can definitely see how his implementation of a
single-linked-list can be observed as "overkill". Personally, if I were
creating a robust container library, I think I would create several levels
of abstraction. Maybe something like:


1. super simple and highly efficient intrusive base implementation.

2. a higher level non-intrusive implementation based on `1'.

3. an even higher level implementation that allows for different objects to
be stored in the same list, again based on `1'.

4. perhaps another higher level that allows for custom allocators and
serialization, probably based on `3'.

Then, you will miss finding something in that list, adding something to
the list in the middle, etc etc.

What is that library about is not the sample implementation (as I have
repeated here thousand times) but a SPECIFICATION.

You can use that specification for implementing a linked list with
almost no overhead, no vtable, no read only flag, no allocator and use
THE SAME SPECIFICATION for interfacing with the list as I do.

THEN

You will be able to switch between the no frills implementation and the
full blown (bloat if you will) with NO CHANGES to user code just linking
with a different implementation!

THAT IS WHAT THIS LIBRARY IS ABOUT.

jacob

 

[Chris M. Thomasson]

Le 09/09/10 04:47, Chris M. Thomasson a écrit :

Why don't you show us how it's done properly.

I don't know about James, but I do think that his container library can
be
useful. Although, I can definitely see how his implementation of a
single-linked-list can be observed as "overkill". Personally, if I were
creating a robust container library, I think I would create several
levels
of abstraction. Maybe something like: [...]

Then, you will miss finding something in that list, adding something to
the list in the middle, etc etc.

Indeed. The impl I quickly typed out in the news reader definitely did not
include any other functionality besides push/pop. Too lazy perhaps? Ouch...
;^(

What is that library about is not the sample implementation (as I have
repeated here thousand times) but a SPECIFICATION.

AFAICT, from the bit I have skimmed, you are going a good job.

You can use that specification for implementing a linked list with almost
no overhead, no vtable, no read only flag, no allocator and use THE SAME
SPECIFICATION for interfacing with the list as I do.

Hey, that sounds great! :^)

It should great on a platform that lacks a dynamic heap (e.g., embedded
non-hosted, scarce resources, ect).

THEN

You will be able to switch between the no frills implementation and the
full blown (bloat if you will) with NO CHANGES to user code just linking

Ahhh... Would I link to a single list object file... Well, perhaps if the
compiler has link time optimization. I would prefer to use header only impl
for such a simple data-structure so the compiler has direct access to the
source code. The good thing seems to be that the specification you are
providing would allow a conforming implementation to be completely header
based.

with a different implementation!

THAT IS WHAT THIS LIBRARY IS ABOUT.

It's a worthwhile endeavor Jacob.

IMVVVHO, C is in need of some sort of standard container library.


Heck, just like in C++, if I choose to implement a single linked list
myself, well, then so be it; I do not need to use the STL... BTW, STL is
non-intrusive, so I was forced to implement intrusive containers for myself
a while ago!

;^)

 

[Tom St Denis]

The project is going forward slowly but surely. I am trying to fix the
bugs in the standard implementation, improve the specs, eliminate
inconsistencies fo the definitions/interface of different containers, etc..

The doc is no longer written in Word/Open Office, whatever. I have
changed to latex (pdflatex) and the looks have improved a lot.

The libraries compile under Macintosh (64 bits), Windows 7 (64 and 32
bits) and linux (64 and 32 bits)

Some pieces of advice from one library developer to another

1. Organize the collection better, the zip file shouldn't have files
in its root, it should be something like "libcontainer-1.0.0/" as the
root, put the version number in the directory name

2. Put your source files under src/ and headers in headers/

3. Split large files up, use directories per container if you want to
make it cleaner e.g. src/redblack/, src/hash/, ..., it also makes
builds faster/easier if the files are smaller (also makes working on
the library easier as you don't need to rebuild it all the time).

4. Split up your containers.h file, 41K is a bit excessive. If they
are truly unrelated containers consider a framework where people can
do something like "#include <containers/redblack.h>" to only include
the header text they need to.

5. Consider a *NIX/*BSD friendly install script to install into /usr/
local/lib and /usr/local/include/containers/

6. In your lcc makefile consider replacing "C:\lcc\include\" with a
variable like LCCDIR so that you can easily move it around

7. Split your testing file into files so that way people can test
just what they want [as the project gets bigger this may become
important for testing cycles].

8. Consider automating the testing from within your makefile

9. Consider a way through defines to enable/disable containers such
that they're not defined/tested in automated builds [e.g. if I don't
want to use the DictionaryContainer I can undef it and build the
library, put a #ifdef around the header data to speed up builds, etc].

10. The manual looks really nice

11. Might want to consider adding some benchmark code to the suite

Hope you get this post and read it

Tom

 

[Tom St Denis]

The project is going forward slowly but surely. I am trying to fix the
bugs in the standard implementation, improve the specs, eliminate
inconsistencies fo the definitions/interface of different containers, etc.

The doc is no longer written in Word/Open Office, whatever. I have
changed to latex (pdflatex) and the looks have improved a lot.

The libraries compile under Macintosh (64 bits), Windows 7 (64 and 32
bits) and linux (64 and 32 bits)

Some pieces of advice from one library developer to another

1.  Organize the collection better, the zip file shouldn't have files
in its root, it should be something like "libcontainer-1.0.0/" as the
root, put the version number in the directory name

2.  Put your source files under src/ and headers in headers/

3.  Split large files up, use directories per container if you want to
make it cleaner e.g. src/redblack/, src/hash/, ..., it also makes
builds faster/easier if the files are smaller (also makes working on
the library easier as you don't need to rebuild it all the time).

4.  Split up your containers.h file, 41K is a bit excessive.  If they
are truly unrelated containers consider a framework where people can
do something like "#include <containers/redblack.h>" to only include
the header text they need to.

5.  Consider a *NIX/*BSD friendly install script to install into /usr/
local/lib and /usr/local/include/containers/

6.  In your lcc makefile consider replacing "C:\lcc\include\" with a
variable like LCCDIR so that you can easily move it around

7.  Split your testing file into files so that way people can test
just what they want [as the project gets bigger this may become
important for testing cycles].

8.  Consider automating the testing from within your makefile

9.  Consider a way through defines to enable/disable containers such
that they're not defined/tested in automated builds [e.g. if I don't
want to use the DictionaryContainer I can undef it and build the
library, put a #ifdef around the header data to speed up builds, etc].

10.  The manual looks really nice

11.  Might want to consider adding some benchmark code to the suite

12. Put a LICENSE file in the archive. It's not clear [from my skim
of the website or glance at the archive] what the license terms are.

Tom

 

[Keith Thompson]

5. Consider a *NIX/*BSD friendly install script to install into /usr/
local/lib and /usr/local/include/containers/

And let the user specify the installation prefix.

 

[Tom St Denis]

And let the user specify the installation prefix.

That'd be ideal as well. At the very least don't install into /usr/
lib and /usr/include...

Tom