Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #23207 > unrolled thread

The C Containers Library

Back to article view | Back to comp.lang.c

Contents

  The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-08 21:53 +0200
    Re: The C Containers Library aftnix <aftnix@gmail.com> - 2012-07-26 13:13 -0700
      Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-26 22:31 +0200
        Re: The C Containers Library lawrence.jones@siemens.com - 2012-07-28 17:46 -0400
          Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-29 02:05 +0200
            Re: The C Containers Library lawrence.jones@siemens.com - 2012-07-30 14:48 -0400
            Re: The C Containers Library Phil Bradby <nospam@nospam.com> - 2012-08-01 21:00 +0000
              Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-08-01 23:18 +0200
              Re: The C Containers Library Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-02 00:48 -0700
                Re: The C Containers Library James Kuyper <jameskuyper@verizon.net> - 2012-08-02 07:00 -0400
                  Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-08-02 13:27 +0200
                    Re: The C Containers Library Quentin Pope <qp19433@hotmail.NOSPAM.com> - 2012-08-02 20:27 +0000
                  Re: The C Containers Library Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-02 05:13 -0700
                  Re: The C Containers Library Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-02 14:26 -0700
                    Re: The C Containers Library Kenneth Brody <kenbrody@spamcop.net> - 2012-08-03 10:47 -0400
          Re: The C Containers Library Noob <root@localhost> - 2012-07-29 09:58 +0200
            Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-30 00:31 -0600
              Re: The C Containers Library Noob <root@localhost> - 2012-07-30 09:45 +0200
                Re: The C Containers Library Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-07-30 02:10 -0700
            Re: The C Containers Library lawrence.jones@siemens.com - 2012-07-30 14:54 -0400
      Re: The C Containers Library James Kuyper <jameskuyper@verizon.net> - 2012-07-26 16:52 -0400
        Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-26 22:56 +0200
          Re: The C Containers Library pacman@kosh.dhis.org (Alan Curry) - 2012-07-26 22:29 +0000
            Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-27 01:50 +0200
              Re: The C Containers Library pacman@kosh.dhis.org (Alan Curry) - 2012-07-27 22:28 +0000
            Re: The C Containers Library Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-07-29 06:31 -0700
              Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-30 00:26 -0600
                Re: The C Containers Library Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-07-30 02:21 -0700
                  Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-02 02:27 -0600
                    Re: The C Containers Library Rui Maciel <rui.maciel@gmail.com> - 2012-08-02 16:43 +0100
                      Re: The C Containers Library Ansel <lateknightdev@gmail.com> - 2012-08-02 17:07 -0700
                        Re: The C Containers Library Rui Maciel <rui.maciel@gmail.com> - 2012-08-03 22:21 +0100
                          Re: The C Containers Library Ansel <lateknightdev@gmail.com> - 2012-08-03 15:43 -0700
                            Re: The C Containers Library Anders Wegge Keller <wegge@wegge.dk> - 2012-08-04 06:32 +0200
                              Re: The C Containers Library Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-04 01:52 -0700
                                Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-04 22:36 -0600
                                  Re: The C Containers Library Anders Wegge Keller <wegge@wegge.dk> - 2012-08-05 08:36 +0200
                                    Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-05 01:28 -0600
                                      Re: The C Containers Library Anders Wegge Keller <wegge@wegge.dk> - 2012-08-05 11:31 +0200
                                        Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-05 03:48 -0600
              Re: The C Containers Library Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-04 03:41 -0700
          Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-27 01:55 +0200
    Re: The C Containers Library wkaras@yahoo.com - 2012-07-26 13:45 -0700
      Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-26 22:53 +0200
        Re: The C Containers Library wkaras@yahoo.com - 2012-07-26 18:46 -0700
          Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-27 10:59 +0200
            Re: The C Containers Library gwowen <gwowen@gmail.com> - 2012-07-27 03:39 -0700
            Re: The C Containers Library wkaras@yahoo.com - 2012-07-27 11:34 -0700
          Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-27 11:04 +0200
            Re: The C Containers Library W Karas <wkaras@yahoo.com> - 2012-07-27 13:10 -0700
    Re: The C Containers Library wkaras@yahoo.com - 2012-07-26 18:54 -0700
      Re: The C Containers Library James Kuyper <jameskuyper@verizon.net> - 2012-07-27 10:25 -0400
        Re: The C Containers Library wkaras@yahoo.com - 2012-07-27 11:28 -0700
          Re: The C Containers Library James Kuyper <jameskuyper@verizon.net> - 2012-07-27 15:17 -0400
            Re: The C Containers Library wkaras@yahoo.com - 2012-07-27 13:00 -0700
            Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-29 02:02 +0200
              Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-28 22:08 -0600
                Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-29 08:46 +0200
                  Re: The C Containers Library pacman@kosh.dhis.org (Alan Curry) - 2012-07-29 07:43 +0000
                    Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-29 09:59 +0200
                      Re: The C Containers Library Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-07-29 06:43 -0700
                      Re: The C Containers Library pacman@kosh.dhis.org (Alan Curry) - 2012-07-29 17:27 +0000
                        Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-29 20:56 +0200
                          Re: The C Containers Library pacman@kosh.dhis.org (Alan Curry) - 2012-07-30 00:07 +0000
                          Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-30 00:07 -0600
                        Re: The C Containers Library Keith Thompson <kst-u@mib.org> - 2012-07-29 11:58 -0700
                          Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-29 22:06 +0200
                        Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-29 22:23 +0200
                          Re: The C Containers Library Melzzzzz <mel@zzzzz.invalid> - 2012-07-30 00:13 +0200
                            Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-30 00:13 -0600
                              Re: The C Containers Library Keith Thompson <kst-u@mib.org> - 2012-07-30 01:10 -0700
                                Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-30 02:57 -0600
                                  Re: The C Containers Library Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-07-30 15:47 +0000
                                  Re: The C Containers Library Keith Thompson <kst-u@mib.org> - 2012-07-30 13:01 -0700
                                Re: The C Containers Library Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-07-30 04:53 -0700
                                  Re: The C Containers Library Keith Thompson <kst-u@mib.org> - 2012-07-30 13:04 -0700
                                  Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-02 02:11 -0600
                                    Re: The C Containers Library James Kuyper <jameskuyper@verizon.net> - 2012-08-02 06:52 -0400
                                  Re: The C Containers Library James Kuyper <jameskuyper@verizon.net> - 2012-08-02 06:46 -0400
                          Re: The C Containers Library Rui Maciel <rui.maciel@gmail.com> - 2012-07-30 00:41 +0100
                            Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-30 09:45 +0200
                    Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-29 23:05 -0600
                  Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-29 22:52 -0600
                    Re: The C Containers Library Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-07-30 04:56 -0700
                      Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-02 02:07 -0600
                    Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-30 17:49 +0200
          Re: The C Containers Library Rui Maciel <rui.maciel@gmail.com> - 2012-07-28 09:17 +0100
            Re: The C Containers Library W Karas <wkaras@yahoo.com> - 2012-07-28 15:17 -0700
              Re: The C Containers Library Rui Maciel <rui.maciel@gmail.com> - 2012-07-29 11:10 +0100
          Re: The C Containers Library Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-28 06:51 -0700
            Re: The C Containers Library Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-28 17:23 +0100
              Re: The C Containers Library Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-30 13:40 -0700
                Re: The C Containers Library Melzzzzz <mel@zzzzz.invalid> - 2012-07-31 00:24 +0200
            Re: The C Containers Library Melzzzzz <mel@zzzzz.invalid> - 2012-07-31 00:05 +0200
            Re: The C Containers Library Rui Maciel <rui.maciel@gmail.com> - 2012-07-31 00:53 +0100
              Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-07-31 09:24 +0200
              Re: The C Containers Library Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-02 14:45 -0700
                Re: The C Containers Library Rui Maciel <rui.maciel@gmail.com> - 2012-08-03 22:31 +0100
                  Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-08-04 00:01 +0200
                    Re: The C Containers Library Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-03 23:45 +0100
                      Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-04 22:47 -0600
                    Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-04 22:41 -0600
                    Re: The C Containers Library Rui Maciel <rui.maciel@gmail.com> - 2012-08-07 10:24 +0100
                      Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-08-07 15:30 +0200
                        Re: The C Containers Library Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-07 15:35 +0100
                          Re: The C Containers Library Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 12:40 -0700
                            Re: The C Containers Library Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-08 00:07 +0100
                              Re: The C Containers Library Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 17:31 -0700
                                Re: The C Containers Library Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-08 03:14 +0100
                                  Re: The C Containers Library Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-08 05:22 -0700
                        Re: The C Containers Library Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 12:36 -0700
                      Re: The C Containers Library Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-08 02:26 -0700
                        Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-08-08 17:25 +0200
              Re: The C Containers Library 88888 Dihedral <dihedral88888@googlemail.com> - 2012-08-03 16:04 -0700
    Re: The C Containers Library SG <s.gesemann@gmail.com> - 2012-08-04 04:52 -0700
      Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-08-04 18:42 +0200
        Re: The C Containers Library Ike Naar <ike@faeroes.freeshell.org> - 2012-08-04 19:17 +0000
          Re: The C Containers Library Ike Naar <ike@faeroes.freeshell.org> - 2012-08-04 19:22 +0000
          Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-08-04 22:14 +0200
          Re: The C Containers Library jacob navia <jacob@spamsink.net> - 2012-08-05 00:15 +0200
            Re: The C Containers Library Ike Naar <ike@faeroes.freeshell.org> - 2012-08-04 23:13 +0000
              Re: The C Containers Library "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-04 22:53 -0600

Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7  Next page →

#24197

On Jul 29, 2:31 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On Jul 26, 11:29 pm, pac...@kosh.dhis.org (Alan Curry) wrote:

> > ISO standards are written like legislation, not documentation. The
> > target audience isn't programmers who want to use the language; it's
> > lawyers who want to be able to officially place blame when something
> > goes wrong.
>
> the term "language lawyer" is a metaphor. The standard is intended to
> supply an unambiguous defintion of the language.

ah yes
http://catb.org/jargon/html/L/language-lawyer.html

[toc] | [prev] | [next] | [standalone]

#23772

Le 26/07/12 22:56, jacob navia a écrit :
> Le 26/07/12 22:52, James Kuyper a écrit :
>> On the other hand, someone as
>> unsympathetic as jacob is to the use of standardese is unlikely to
>> perform a good translation, so perhaps it is best if he doesn't even
>> try.

Sorry I misunderstood what you said.

I read:

 >> On the other hand, someone as
 >> unsympathetic as jacob

Then in my mind I added a comma here, so that sentence was separated
from the rest and thought you were treating me of "unsympathetic"

I am getting completely paranoid, actually now in a second reading I see 
that you are referring to me as being unsympathetic to standardese
what is correct.

That is why I asked for a translation.

Well, now is clearer.


Sorry about this confusion.

[toc] | [prev] | [next] | [standalone]

#23757

On Sunday, July 8, 2012 3:53:07 PM UTC-4, jacob navia wrote:
> To:
> John Benito
> Convener
> 	  ISO/IEC JTC1/SC22/WG14
>            110 Shady Brook Court
>            Santa Cruz, CA 95065-9728
>            USA
> 
> From:
> 
> Jacob Navia
> 41 rue Maurice Ravel
> 93430 Villetaneuse
> France
> 
>                                 Villetaneuse, July 8th 2012
> 
> Dear Sir,
> 
> I would like to present the document:
> 
> "The C Containers Library"
> 
> to the committee for consideration for standardization.
> 
> This document has been discussed in the French C++ standardization
> group of the AFNOR since there isn't a group for the C language
> exclusively any more. C and C++ share the same group.
> 
> This document is available at the following address:
> 
> http://ccl.googlecode.com/files/ccl.pdf
> 
> I have setup a google project with the source code of the sample
> implementation as described in the above document. Its address is:
> 
> http://code.google.com/p/ccl/
> 
> I have been working in this project approximately for three years and
> the document is still far from perfect, but I consider that it now
> gives a clear idea of the scope of this undertaking and about how can
> it be implemented.
> 
> I presented the very first release of this project on June 24th 2010
> to the comp.std.c and comp.lang.c discussions groups. I had started to
> design and implement the library approximately a year before.
> 
> In the document you will find:
> 
> o An introduction that describes the layout, the motivations, and an
>    overview of what parts of the document are to be considered normative
>    specifications.
> o Two introductory chapters explaining things informally.
> o Two normative chapters (Auxiliary interfaces and the Containers)
> o A description of the sample implementation with some commented code
>    excerpts.
> o Applications and examples
> o The "templated" form of the containers explained.
> 
> I have tried to keep the language of the specifications clear and
> concise, but I have avoided trying to mimic "standardese" since I
> believe that the explanations should be understood by all programmers
> using the library without any artificial restrictions. As a model, I
> used the language used in the "RFC"s of the interenet, specifications
> that proved quite useful but are in plain language, understood by
> everyone.
> 
> My goal in this first approach is to start a technical report (TR) that
> could be further discussed within the community.
> 
> I thank you in advance for your attention. I remain available at any
> time for any question you may have concerning this project.
> 
> Yours sincerely
> 
> Jacob Navia
> Programmer

Although this clearly has value as it is, I think it would be an improvement if these non-intrusive containers were layered on top of intrusive containers.

[toc] | [prev] | [next] | [standalone]

#23759

Le 26/07/12 22:45, wkaras@yahoo.com a écrit :

> Although this clearly has value as it is, I think it would be an improvement

if these non-intrusive containers were layered on top of intrusive 
containers.
>

How can you maintain the inner structure of the container hidden in 
intrusive containers?

Please explain

jacob

[toc] | [prev] | [next] | [standalone]

#23778

On Thursday, July 26, 2012 4:53:40 PM UTC-4, jacob navia wrote:
> Le 26/07/12 22:45, wkaras a �crit :
> 
> > Although this clearly has value as it is, I think it would be an improvement
> 
> if these non-intrusive containers were layered on top of intrusive 
> containers.
> >
> 
> How can you maintain the inner structure of the container hidden in 
> intrusive containers?
> 
> Please explain
> 
> jacob

It's not hidden, that's part of the instrusive aspect of it.  If you look at the examples using this intrusive AVL tree code that I wrote:

http://wkaras.webs.com/cavl_tree.html

maybe that would be the best way to show you what I mean.  The Boost library also now has instrusive containers (in C++ of course) but simpler if somewhat less flexible.

I'm address more your example implementation (which I'm guessing is highly portable).  I'm just suggesting it might be worth the effort to repackage the container implementations as directly-usable instrusive containers, and have the intrusive containers become an optional layer on top.

There could be some minor performance penalties.  For example, a straight-forward instrusive AVL tree would require the element to be contained (without copying) to have within it the structure:

typedef struct { void *left, *right; char balance_factor; } AVL_FIELDS;

The container could insist this struct be at byte offset 0 in the element.  Or the offset could be configurable for each container, allowing an element to be in multiple trees (or other containers) as the same time.  The cost being the added overhead of getting and adding the offset each time AVL_FIELDS is referenced.

[toc] | [prev] | [next] | [standalone]

#23788

Le 27/07/12 03:46, wkaras@yahoo.com a écrit :
> On Thursday, July 26, 2012 4:53:40 PM UTC-4, jacob navia wrote:
>> Le 26/07/12 22:45, wkaras a �crit :
>>
>> > Although this clearly has value as it is, I think it would be an improvement
>>
>> if these non-intrusive containers were layered on top of intrusive
>> containers.
>> >
>>
>> How can you maintain the inner structure of the container hidden in
>> intrusive containers?
>>
>> Please explain
>>
>> jacob
>
> It's not hidden, that's part of the instrusive aspect of it.  If you look at the examples using this intrusive AVL tree code that I wrote:
>
> http://wkaras.webs.com/cavl_tree.html
>

That address doesn't work: I get a 404...

[toc] | [prev] | [next] | [standalone]

#23791

On Jul 27, 9:59 am, jacob navia <ja...@spamsink.net> wrote:

> >http://wkaras.webs.com/cavl_tree.html
>
> That address doesn't work: I get a 404...

http://www.oocities.org/wkaras/gen_c/cavl_tree.html

[toc] | [prev] | [next] | [standalone]

#23805

On Friday, July 27, 2012 4:59:59 AM UTC-4, jacob navia wrote:
> Le 27/07/12 03:46, wkaras a �crit :
> 
> > On Thursday, July 26, 2012 4:53:40 PM UTC-4, jacob navia wrote:
> 
> >> Le 26/07/12 22:45, wkaras a �crit :
> 
> >>
> 
> >> > Although this clearly has value as it is, I think it would be an improvement
> 
> >>
> 
> >> if these non-intrusive containers were layered on top of intrusive
> 
> >> containers.
> 
> >> >
> 
> >>
> 
> >> How can you maintain the inner structure of the container hidden in
> 
> >> intrusive containers?
> 
> >>
> 
> >> Please explain
> 
> >>
> 
> >> jacob
> 
> >
> 
> > It's not hidden, that's part of the instrusive aspect of it.  If you look at the examples using this intrusive AVL tree code that I wrote:
> 
> >
> 
> > http://wkaras.webs.com/cavl_tree.html
> 
> >
> 
> 
> 
> That address doesn't work: I get a 404...

Ooops.  http://wkaras.webs.com/gen_c/cavl_tree.html

( http://www.oocities.org/wkaras/gen_c/cavl_tree.html is an identical copy.)

[toc] | [prev] | [next] | [standalone]

#23789

I see what you mean, but the problem is that there is no separation from 
the container to the rest of the software...

That means that any ch	ange of the container structure that can't be
hidden needs a complete recompilation of all the client software.

OK, some containers like single linked lists could be easy to do
bit others would be much more complex.

The way the AI would look would need to be radically different
too.

I will wait till your address

http://wkaras.webs.com/cavl_tree.html

to see what you have in mind concerning the API.

[toc] | [prev] | [next] | [standalone]

#23809

On Friday, July 27, 2012 5:04:12 AM UTC-4, jacob navia wrote:
> I see what you mean, but the problem is that there is no separation from 
> 
> the container to the rest of the software...
> 
> 
> 
> That means that any ch	ange of the container structure that can't be
> 
> hidden needs a complete recompilation of all the client software.
> 
> 
> 
> OK, some containers like single linked lists could be easy to do
> 
> bit others would be much more complex.
> 
> 
> 
> The way the AI would look would need to be radically different
> 
> too.
> 
> 
> 
> I will wait till your address
> 
> 
> 
> http://wkaras.webs.com/cavl_tree.html
> 
> 
> 
> to see what you have in mind concerning the API.

This a valid disadvantages of instrusive containers.  But in some cases they are outweighed by the advantages.  The elements of intrusive containers can be the original ones, not copies.  Elements are not restricted to being in the heap, or anywhere else.  If the intrusive containers are designed to allow it, elements can be in multiple containers at once.

Again, to be clear, I am not saying you should not provide non-intrusive containers in your implementation.  I'm saying split it into two layers, non-intrusive on top of intrusive, so users can use the bottom layer without the top when appropriate.

[toc] | [prev] | [next] | [standalone]

#23780

On Sunday, July 8, 2012 3:53:07 PM UTC-4, jacob navia wrote:
> To:
> John Benito
> Convener
> 	  ISO/IEC JTC1/SC22/WG14
>            110 Shady Brook Court
>            Santa Cruz, CA 95065-9728
>            USA
> 
> From:
> 
> Jacob Navia
> 41 rue Maurice Ravel
> 93430 Villetaneuse
> France
> 
>                                 Villetaneuse, July 8th 2012
> 
> Dear Sir,
> 
> I would like to present the document:
> 
> "The C Containers Library"
> 
> to the committee for consideration for standardization.
> 
> This document has been discussed in the French C++ standardization
> group of the AFNOR since there isn't a group for the C language
> exclusively any more. C and C++ share the same group.
> 
> This document is available at the following address:
> 
> http://ccl.googlecode.com/files/ccl.pdf
> 
> I have setup a google project with the source code of the sample
> implementation as described in the above document. Its address is:
> 
> http://code.google.com/p/ccl/
> 
> I have been working in this project approximately for three years and
> the document is still far from perfect, but I consider that it now
> gives a clear idea of the scope of this undertaking and about how can
> it be implemented.
> 
> I presented the very first release of this project on June 24th 2010
> to the comp.std.c and comp.lang.c discussions groups. I had started to
> design and implement the library approximately a year before.
> 
> In the document you will find:
> 
> o An introduction that describes the layout, the motivations, and an
>    overview of what parts of the document are to be considered normative
>    specifications.
> o Two introductory chapters explaining things informally.
> o Two normative chapters (Auxiliary interfaces and the Containers)
> o A description of the sample implementation with some commented code
>    excerpts.
> o Applications and examples
> o The "templated" form of the containers explained.
> 
> I have tried to keep the language of the specifications clear and
> concise, but I have avoided trying to mimic "standardese" since I
> believe that the explanations should be understood by all programmers
> using the library without any artificial restrictions. As a model, I
> used the language used in the "RFC"s of the interenet, specifications
> that proved quite useful but are in plain language, understood by
> everyone.
> 
> My goal in this first approach is to start a technical report (TR) that
> could be further discussed within the community.
> 
> I thank you in advance for your attention. I remain available at any
> time for any question you may have concerning this project.
> 
> Yours sincerely
> 
> Jacob Navia
> Programmer

I would just comment generally that the C++ STL started out as an implementation, the standardese came later.  And I don't believe it was Stepanov who wrote the standardese.

I prefer a portable open-source implementation even with no standard to standard with no portable open-source implementation.

[toc] | [prev] | [next] | [standalone]

#23795

On 07/26/2012 09:54 PM, wkaras@yahoo.com wrote:
> On Sunday, July 8, 2012 3:53:07 PM UTC-4, jacob navia wrote:
...
>> I have tried to keep the language of the specifications clear and
>> concise, but I have avoided trying to mimic "standardese" since I
>> believe that the explanations should be understood by all programmers
>> using the library without any artificial restrictions. As a model, I
>> used the language used in the "RFC"s of the interenet, specifications
>> that proved quite useful but are in plain language, understood by
>> everyone.
...
> I would just comment generally that the C++ STL started out as an implementation, the standardese came later.  And I don't believe it was Stepanov who wrote the standardese.

Yes, and getting the standardese right was a major pain for the C++
committee, judging from the discussions I saw on comp.std.c++. They were
willing to make that effort because they considered the STL a major
valuable addition to C++. Jacob faces the challenge of getting the C
committee comparably enthusiastic about the "C Containers Library".

[toc] | [prev] | [next] | [standalone]

#23806

On Friday, July 27, 2012 10:25:57 AM UTC-4, James Kuyper wrote:
> On 07/26/2012 09:54 PM, wkaras wrote:
> 
> > On Sunday, July 8, 2012 3:53:07 PM UTC-4, jacob navia wrote:
> 
> ...
> 
> >> I have tried to keep the language of the specifications clear and
> 
> >> concise, but I have avoided trying to mimic "standardese" since I
> 
> >> believe that the explanations should be understood by all programmers
> 
> >> using the library without any artificial restrictions. As a model, I
> 
> >> used the language used in the "RFC"s of the interenet, specifications
> 
> >> that proved quite useful but are in plain language, understood by
> 
> >> everyone.
> 
> ...
> 
> > I would just comment generally that the C++ STL started out as an implementation, the standardese came later.  And I don't believe it was Stepanov who wrote the standardese.
> 
> 
> 
> Yes, and getting the standardese right was a major pain for the C++
> 
> committee, judging from the discussions I saw on comp.std.c++. They were
> 
> willing to make that effort because they considered the STL a major
> 
> valuable addition to C++. Jacob faces the challenge of getting the C
> 
> committee comparably enthusiastic about the "C Containers Library".

The STL containers have been a big driver of adoption of C++ in place of C.  A powerful C container library (which this appears to be) would be very important to maintaining C as a viable alternative.  So it should not be that big of a challenge.

[toc] | [prev] | [next] | [standalone]

#23807

On 07/27/2012 02:28 PM, wkaras@yahoo.com wrote:
> On Friday, July 27, 2012 10:25:57 AM UTC-4, James Kuyper wrote:
>> On 07/26/2012 09:54 PM, wkaras wrote:
...
>>> I would just comment generally that the C++ STL started out as an implementation, the standardese came later.  And I don't believe it was Stepanov who wrote the standardese.
>>
>>
>>
>> Yes, and getting the standardese right was a major pain for the C++
>>
>> committee, judging from the discussions I saw on comp.std.c++. They were
>>
>> willing to make that effort because they considered the STL a major
>>
>> valuable addition to C++. Jacob faces the challenge of getting the C
>>
>> committee comparably enthusiastic about the "C Containers Library".
> 
> The STL containers have been a big driver of adoption of C++ in place of C.  A powerful C container library (which this appears to be) would be very important to maintaining C as a viable alternative.  So it should not be that big of a challenge.

C++ has many features which are not part of C, that made STL powerful
while remaining relatively easy to implement and use. Adding those
features to C would remove much of the distinction between C and C++.
The only point in keeping C and C++ alive simultaneously is the
differences between them - C is the simpler, easier language to
implement, learn, and read; C++ is the more complicated higher-level
language that makes certain concepts (such as STL) a lot easier to
implement and use. C would lose most of that simplicity advantage if all
of those C++ features were added to it.

jacob has proposed that some of those features be added, but not all of
them; in any event that's not what this proposal is about. The
Containers Library is a kludge that attempts to work somewhat like STL,
without all of the C++-specific features that STL relies upon, and
that's what's going to make this a difficult concept to sell to the
committee.

[toc] | [prev] | [next] | [standalone]

#23808

On Friday, July 27, 2012 3:17:29 PM UTC-4, James Kuyper wrote:
> On 07/27/2012 02:28 PM, wkaras wrote:
> 
> > On Friday, July 27, 2012 10:25:57 AM UTC-4, James Kuyper wrote:
> 
> >> On 07/26/2012 09:54 PM, wkaras wrote:
> 
> ...
> 
> >>> I would just comment generally that the C++ STL started out as an implementation, the standardese came later.  And I don't believe it was Stepanov who wrote the standardese.
> 
> >>
> 
> >>
> 
> >>
> 
> >> Yes, and getting the standardese right was a major pain for the C++
> 
> >>
> 
> >> committee, judging from the discussions I saw on comp.std.c++. They were
> 
> >>
> 
> >> willing to make that effort because they considered the STL a major
> 
> >>
> 
> >> valuable addition to C++. Jacob faces the challenge of getting the C
> 
> >>
> 
> >> committee comparably enthusiastic about the "C Containers Library".
> 
> > 
> 
> > The STL containers have been a big driver of adoption of C++ in place of C.  A powerful C container library (which this appears to be) would be very important to maintaining C as a viable alternative.  So it should not be that big of a challenge.
> 
> 
> 
> C++ has many features which are not part of C, that made STL powerful
> 
> while remaining relatively easy to implement and use. Adding those
> 
> features to C would remove much of the distinction between C and C++.
> 
> The only point in keeping C and C++ alive simultaneously is the
> 
> differences between them - C is the simpler, easier language to
> 
> implement, learn, and read; C++ is the more complicated higher-level
> 
> language that makes certain concepts (such as STL) a lot easier to
> 
> implement and use. C would lose most of that simplicity advantage if all
> 
> of those C++ features were added to it.
> 
> 
> 
> jacob has proposed that some of those features be added, but not all of
> 
> them; in any event that's not what this proposal is about. The
> 
> Containers Library is a kludge that attempts to work somewhat like STL,
> 
> without all of the C++-specific features that STL relies upon, and
> 
> that's what's going to make this a difficult concept to sell to the
> 
> committee.

Why do you feel it's a kludge?  Because he's using void pointers to make the code generic, that is, usable with different types?  Isn't that why void pointers were added to C, for that purpose?

Containers are not anything esoteric, they are at least as widely used as floating point, to give an example.  Casting mistakes when using void pointers can be hairy.  But the overall effort, and the overall chance of a bug making it into released code, is less than rewriting containers like AVL trees and hash tables over and over for specific types.

[toc] | [prev] | [next] | [standalone]

#23867

Le 27/07/12 21:17, James Kuyper a écrit :
> jacob has proposed that some of those features be added, but not all of
> them; in any event that's not what this proposal is about.

Yes, in the library I have used C89, all C99 features are completely
optional.


> The
> Containers Library is a kludge

says James without the hint of an argument. It *must* be a kludge since
James says so.

> that attempts to work somewhat like STL,

No, since C and C++ are different languages with different approaches.

In C++ the solution to everything is to complexify the language without
bounds.

In C, complex software can be done with simpler tools if you program
carefully. That is why I like C. It allows you to build powerful
software with relatively simple tools. It appeals aesthetically,
I would say.

> without all of the C++-specific features that STL relies upon,

Exactly. Without all that huge machinery I arrive at very similar speeds 
and features.


I find that great!

> and
> that's what's going to make this a difficult concept to sell to the
> committee.

I am not selling something. I would like to convince people though, but 
I am not obtaining any personal gain with this work.

It is just that I like C.

jacob

[toc] | [prev] | [next] | [standalone]

#23876

"jacob navia" <jacob@spamsink.net> wrote in message 
news:jv1uhs$2oj$1@speranza.aioe.org...
> Le 27/07/12 21:17, James Kuyper a écrit :

> No, since C and C++ are different languages with different approaches.
>
> In C++ the solution to everything is to complexify the language without
> bounds.
>
> In C, complex software can be done with simpler tools if you program
> carefully. That is why I like C. It allows you to build powerful
> software with relatively simple tools. It appeals aesthetically,
> I would say.
>
>> without all of the C++-specific features that STL relies upon,
>
> Exactly. Without all that huge machinery I arrive at very similar speeds 
> and features.

Please post a side-by-side syntax comparison (STL vs. your CCL) of a few 
easy container declarations and their usages. A comparison chart of features 
comparing the two would be great also. A "strengths and weakeness" list of 
both would be more nice info. If you throw-in an overall comparison 
paragraph or two, you'd have the start to a "white paper" (maybe)! You'd 
need performance and overhead comparisons then too and an objective 
comparison of implementation characterisitcs beyond "and I did it without 
huge machinery".

I don't think you can go to the conference and *not* compare against STL 
even though you have a C-based product. Else you're going to get responses 
like James gave you about it being kludgy -- you have to address that 
("that" being that C gives one less clay to mold a container library with) 
and try to alleviate those concerns so that no one even thinks to say that. 
Your story needs to be not only convincing, but *compelling*.

Did you start with STL as a design and then subtract until you came up with 
something similar that would work in C? If not, that may very well be a very 
good exercise.

[toc] | [prev] | [next] | [standalone]

#23877

Le 29/07/12 06:08, Ansel a écrit :
> "jacob navia" <jacob@spamsink.net> wrote in message
> news:jv1uhs$2oj$1@speranza.aioe.org...
>> Le 27/07/12 21:17, James Kuyper a écrit :
>
>> No, since C and C++ are different languages with different approaches.
>>
>> In C++ the solution to everything is to complexify the language without
>> bounds.
>>
>> In C, complex software can be done with simpler tools if you program
>> carefully. That is why I like C. It allows you to build powerful
>> software with relatively simple tools. It appeals aesthetically,
>> I would say.
>>
>>> without all of the C++-specific features that STL relies upon,
>>
>> Exactly. Without all that huge machinery I arrive at very similar speeds
>> and features.
>
> Please post a side-by-side syntax comparison (STL vs. your CCL) of a few
> easy container declarations and their usages. A comparison chart of features
> comparing the two would be great also. A "strengths and weakeness" list of
> both would be more nice info. If you throw-in an overall comparison
> paragraph or two, you'd have the start to a "white paper" (maybe)! You'd
> need performance and overhead comparisons then too and an objective
> comparison of implementation characterisitcs beyond "and I did it without
> huge machinery".
>
> I don't think you can go to the conference and *not* compare against STL
> even though you have a C-based product. Else you're going to get responses
> like James gave you about it being kludgy -- you have to address that
> ("that" being that C gives one less clay to mold a container library with)
> and try to alleviate those concerns so that no one even thinks to say that.
> Your story needs to be not only convincing, but *compelling*.
>
> Did you start with STL as a design and then subtract until you came up with
> something similar that would work in C? If not, that may very well be a very
> good exercise.
>
>

No, I will not do that. The library is not a direct competition for the
STL, C++ is the best thing since sliced bread, and people that like
that machinery because they have been building it since years would fall
on me and my small project like hawks...

C++ people tend to look upon simpler tools like C with disdain since
by their very existence they show that another (simpler) way is possible
in software development; a way that leads maybe into less complexity
than what C++ offers now. But I am not pushing that, and I do not see
C++ people abandoning C++ to come to C. I see C programmers having
more fun with C since they do not have to implement a list AGAIN and AGAIN.

I see the library a a develomment of the C language, independent of C++.

Not as a competitor.

And I stay to this:

 >> In C, complex software can be done with simple tools if you program
 >> carefully. That is why I like C. It allows you to build powerful
 >> software with relatively simple tools. It appeals aesthetically,
 >> I would say.

jacob

[toc] | [prev] | [next] | [standalone]

#23878

In article <jv2m8d$ir8$1@speranza.aioe.org>,
jacob navia  <jacob@jspamsink.org> wrote:
>Le 29/07/12 06:08, Ansel a écrit :
>>
>> I don't think you can go to the conference and *not* compare against STL
>> even though you have a C-based product. Else you're going to get responses
>> like James gave you about it being kludgy -- you have to address that
>> ("that" being that C gives one less clay to mold a container library with)
>> and try to alleviate those concerns so that no one even thinks to say that.
>> Your story needs to be not only convincing, but *compelling*.
>>
[...]
>
>No, I will not do that. The library is not a direct competition for the
>STL, C++ is the best thing since sliced bread, and people that like
>that machinery because they have been building it since years would fall
>on me and my small project like hawks...

Could you do a side-by-side with GLib? It has linked lists, trees,
hashes... it's not exactly the same thing, but there is significant
overlap. It's a C library, so it's closer to being your real
competition.

In fact if someone showed up at the C committee meeting and said "hey,
how about we standardize GLib?" they'd probably have a better chance of
success than you right now. GLib is ugly as hell, but it has actual
field testing.

-- 
Alan Curry

[toc] | [prev] | [next] | [standalone]

#23880

Le 29/07/12 09:43, Alan Curry a écrit :
> In article <jv2m8d$ir8$1@speranza.aioe.org>,
> jacob navia  <jacob@jspamsink.org> wrote:
>> Le 29/07/12 06:08, Ansel a écrit :
>>>
>>> I don't think you can go to the conference and *not* compare against STL
>>> even though you have a C-based product. Else you're going to get responses
>>> like James gave you about it being kludgy -- you have to address that
>>> ("that" being that C gives one less clay to mold a container library with)
>>> and try to alleviate those concerns so that no one even thinks to say that.
>>> Your story needs to be not only convincing, but *compelling*.
>>>
> [...]
>>
>> No, I will not do that. The library is not a direct competition for the
>> STL, C++ is the best thing since sliced bread, and people that like
>> that machinery because they have been building it since years would fall
>> on me and my small project like hawks...
>
> Could you do a side-by-side with GLib? It has linked lists, trees,
> hashes... it's not exactly the same thing, but there is significant
> overlap. It's a C library, so it's closer to being your real
> competition.
>
> In fact if someone showed up at the C committee meeting and said "hey,
> how about we standardize GLib?" they'd probably have a better chance of
> success than you right now. GLib is ugly as hell, but it has actual
> field testing.
>

We have discussed the glib several times in this group. Specifically, 
the behavior of "xmalloc" of the glib was questioned that aborts the
program instead of returning NULL.

The basic problem is that the glib is GNU, and that means that it can't
be used outside the restrictions of the GPL.

The sample implementation is not a full implementation of the library.
Multi-threading stuff is missing, for instance. Ordered containers
(keep in sorted order) are missing from this first version too.

[toc] | [prev] | [next] | [standalone]

Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7  Next page →

Back to top | Article view | comp.lang.c

csiph-web