C Containers library

Discussion in 'C Programming' started by jacob navia, Sep 5, 2010.

  1. jacob navia

    jacob navia Guest

    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)
    jacob navia, Sep 5, 2010
    #1
    1. Advertising

  2. jacob navia <> writes:
    > 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.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Sep 5, 2010
    #2
    1. Advertising

  3. On 05/09/2010 23:38, Keith Thompson wrote:
    > 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
    Francois Grieu, Sep 6, 2010
    #3
  4. jacob navia

    James Guest

    "jacob navia" <> wrote in message
    news:i60ush$t65$...
    > 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!


    =^(
    James, Sep 6, 2010
    #4
  5. jacob navia

    Dann Corbit Guest

    In article <i620mm$qqp$>, lid says...
    >
    > "jacob navia" <> wrote in message
    > news:i60ush$t65$...
    > > 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!
    >
    >
    > =^(


    Why don't you show us how it's done properly.
    Dann Corbit, Sep 8, 2010
    #5
  6. "Chris M. Thomasson" <> wrote in message
    news:8VXho.54134$...
    > "Dann Corbit" <> wrote in message
    > news:-september.org...
    >> In article <i620mm$qqp$>, lid says...
    >>>
    >>> "jacob navia" <> wrote in message
    >>> news:i60ush$t65$...
    >>> > 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!
    >>>
    >>>
    >>> =^(

    >>
    >> 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:
    >
    >
    > 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...
    }
    BGB / cr88192, Sep 9, 2010
    #6
  7. jacob navia

    jacob navia Guest

    Le 09/09/10 04:47, Chris M. Thomasson a écrit :
    > "Dann Corbit"<> wrote in message
    > news:-september.org...
    >> In article<i620mm$qqp$>, lid says...


    >> 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:
    >
    >
    > 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
    jacob navia, Sep 9, 2010
    #7
  8. "jacob navia" <> wrote in message
    news:i6a3r2$ce4$...
    > Le 09/09/10 04:47, Chris M. Thomasson a écrit :
    >> "Dann Corbit"<> wrote in message
    >> news:-september.org...
    >>> In article<i620mm$qqp$>, lid says...

    >
    >>> 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!

    ;^)
    Chris M. Thomasson, Sep 9, 2010
    #8
  9. jacob navia

    Tom St Denis Guest

    On Sep 5, 4:34 pm, jacob navia <> wrote:
    > 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, Sep 9, 2010
    #9
  10. jacob navia

    Tom St Denis Guest

    On Sep 9, 9:10 am, Tom St Denis <> wrote:
    > On Sep 5, 4:34 pm, jacob navia <> wrote:
    >
    > > 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
    Tom St Denis, Sep 9, 2010
    #10
  11. Tom St Denis <> writes:
    [...]
    > 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.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Sep 9, 2010
    #11
  12. jacob navia

    Tom St Denis Guest

    On Sep 9, 12:03 pm, Keith Thompson <> wrote:
    > Tom St Denis <> writes:
    > [...]
    >
    > > 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.


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

    Tom
    Tom St Denis, Sep 9, 2010
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ross Boylan
    Replies:
    12
    Views:
    571
    Ross Boylan
    Feb 13, 2004
  2. Bob
    Replies:
    2
    Views:
    298
  3. Replies:
    7
    Views:
    548
    Pete Becker
    Jan 25, 2008
  4. Morten
    Replies:
    3
    Views:
    436
  5. Sebastian Mach
    Replies:
    5
    Views:
    307
Loading...

Share This Page