A container library for the C language

[Ian Collins]

Ian Collins a écrit :
Yes, that has been corrected, see the changelog

No, it hasn't, the definition of getline is still missing.

 

[Ed]

So because C++ has containers, iterators and algorithms, we should not
use data structures, for loops or in fact anything that has any
observable effect on the state of the program?

People seem to forget history: some set out to improve C 25 years ago and
it resulted in C++. The question becomes, what compromises is one willing
to make on that duplicate path/journey? "half way?" What is "half way?".
Setting out to Vegas on a whim is not prudent, especially after a night
at the bar. With the studies and justifications and goals and plans
absent, and without a sober state of mind, I see no reason to embark.
Bypassing all the practicalities is not a way get people bought-in to the
idea. It may even be dishonest. One soliciting the work of others owes it
to them to present the inherent risks and potential of success, and that
CAN be had with a planned and objective approach to see if what is now
just an idea has any merit.

 

[Ed]

OK, I get it. You hate the idea.

I don't "hate" ideas. The idea has not been justified but can be found
out to be justifiable or not by doing the upfront "homework". The idea
will undoubtedly evolve, history shows and this type of project is hardly
unique, so before one starts throwing money into the proverbial black
hole, one should ensure that the idea is sound. Note that ideas are a
dime a dozen and it is only concepts that have value.

Many things have already been done in
C++. OTOH there are many places where C++ cannot be used for a variety
of reasons. Some of these places have uses for containers and writing
a container from scratch is a non-trivial task.

By all means critique someone's code but the above is not that, it is
just a very negative criticism.

Not at all. See above and get my drift. There's a lot more to major
projects than source code.

If 'it has been done before elswhere'
were a reason for not doing something there is not much that most
people could do.

I expect more practicality from programmers when approaching other than
those one-off little programs. Its way to early to be talking about HOW
to do it since WHETHER to do it has not been established (I believe it
has been decided long ago, even if only implicitely).
Individuals/individual companies can do what they want. I am thinking
from a standards-body-sanctioned perspective. Do the homework and
preliminary footwork and it would stand a better chance of getting
consideration. "Here's my drawing from school today. Can I please have it
hung up in the Louvre?", needs more. Much more. From my understanding,
the committee standardizes common practice. It doesn't really invent
anything. So when the techniques become common practice, which would
surely digress to consideration of the introduction of mechanisms to make
any implementation of such a thing elegant, and surely that has been
considered before, I think you end right back where you started: pick the
library you like or build your own and use it, because there is aversion
to adding to the C standard that way (as far as I can tell and as history
seems to indicate) and it hasn't been established that enough of the user
base would benefit from the introduction or that such an introduction
wouldn't actually push more C users to C++.

 

[Ed]

Any new container library is going to be compared against what is
already available. This kind of criticism is to be expected.

I don't see a container library. I see investigation into how to
implement one so I assess there will be nothing good there for a number
of years, perhaps many, or perhaps never. Given that, my attention
focuses curiously on why someone would suggest such a thing for standard
C and why it doesn't have merit. Someone seems to be putting the cart
before the horse, so curiously I wonder why.

In general I feel almost impossible. I think it's possible to
introduce a framework that gets collective support from some portion
of the C community (like GLib), but even hoping for that is quite a
long shot and would require an extraordinary amount of work.

Apparently I'm not the only one who thinks so then.

The
people who were actively working in container research passed C by a
long time ago, and without the prudent thinking of C++ proponents in
the early going before it was standardized, C++ may have missed the
STL and ended up with a similar situation to C; a multitude of vendor
driven container libraries.

There should be more than one, and there are. Should there be a
ISO-blessed one, I guess it can't hurt (well it does hurt those in the
business of selling such libraries and it does stagnate evolution of such
things, so maybe it does/did hurt). The STL is so general that it mostly
appeals to, well I don't know whom. Those enamoured with PLs and those
with very large project budgets for sure.

Can you explain what you mean by going awry in your context?


No, but it's fun to rehash the argument with new attempts (I'm a
relative newcomer to clc). And it beats the usual spam that gets
posted. It got you to post didn't it ;-)

Anyway, I don't think the current proposal will bring C back to life and
I think it would like to RIP.

I also have an interest in generic containers in C, but I don't have
nearly the amount of ambition as Navia has.


While I believe that you will not achieve STL like capability with
template support, I do believe that there is potential; perhaps that's
me being young and foolish though ;-). The main drawback contrast
with C++ is that the C container interface will have to carry the type
around, whether manual casting and sizeof's, or wrapping the interface
with macros. It puts a larger burden on the programmer, but that's
what you get for using C.


I think that PREFERRED is too strong. I'm sure that most people here
think that the concept of a standardized C container library is "a
good thing". I also think that the container library should conform
to the language standard, and not the other way around. Getting
enough people to agreeing on what that library looks like though may
infer that no one could propose a library that could be universally
agreed to be considered the "C standard container library".

Especially since the mechanisms are not in C to support an elegant
implementation so you'd end up with something kludgy and I don't think
the ISO is into kludgy (is it?).

I agree. The best that I think any aspiring C container library would
be is some kind of Boost like use. At the moment, I feel that someone
trying to get a C container library standardized borders on delusions
of grandeur. 30+ years of C and people much smarter than me and still
no standard C container library leaves me with no confidence that it
can be done. However, I enjoy arguing about it on clc.

LOL. OK. No harm in debating. Don't waste too much time though, for time
will inevitably tell all.

 

[Ian Collins]

There should be more than one, and there are. Should there be a
ISO-blessed one, I guess it can't hurt (well it does hurt those in the
business of selling such libraries and it does stagnate evolution of such
things, so maybe it does/did hurt). The STL is so general that it mostly
appeals to, well I don't know whom. Those enamoured with PLs and those
with very large project budgets for sure.

The part of the C++ standard library formally known as the STL is
sufficiently general to appeal to most C++ programmers and projects.
That was the key to its inclusion in the standard library and its
enduring success.

The battle anyone faces when proposing library additions is
demonstrating not only the utility of their proposed solution, but its
acceptance in general use. The STL had been in use for many years
before it was incorporated in the C++ standard and the library
extensions in the next C++ standard have also been available and well
used for many years.

I understand one of the guidelines of the C committee is to standardise
existing practice (which I guess could be interpreted as "maintenance
mode"), so any new library extensions will probably have to wait for C
next +1, assuming they last that long in the wild.

 

[Nick Keighley]

I have been talking about this [a container library for C]
since quite a long time.

I'm not sure I agree his criticism is entirely negative.

It wasn't AT ALL NEGATIVE.
?

There are
some things that are just not worth doing. Writing a compiler in
COBOL.

On the other hand I'm not sure a container library in C is entirely
mad.

And thousands have already done it. So this 10000th time, this one is
going to become a standard? What are the chances? I don't think you can
introduce a construct with "->VTable" in it and appeal to a major portion
of a C audience. There are many things like that in the document he
offered up above which indicates to me that he is quite disillusioned
about the whole concept

ITYM "misinformed", he'll *become* disillusioned if the project goes
as you predict.

of A.) What level of effort and knowledge
creating such a library entails,

he's implemented a C compiler and a suite of libraries to go with it

and B.) What level of evolved quality
such a library would have to attain before being worthy of presentation
to a standards organization, and C.) The "spirit of C" and how to market
to a larger segment of the C user base. To say "here is my ad hoc
container library" is quite different from saying "here is my proposal
for a container library to be in the next C standard".

Not that I'm knocking it. It's just fun to analyze projects and why they
go awry.



Oh. Did any conclusions come out of that back then?

that there were existing container libraries out there, that something
with ->VTable in it would be a hard sell and that Jacob was going to
do it anyway

I was wondering if he knows the "other" language.

C++? I'm guessing he's had some experience of it. It's a big bugger.

Or any other other such
libraries for that matter since his approach seems to be that which has
been rejected eons ago (1993?) by container library developers.


"few" being the keyword (NPI)? Knowing that it will take years to evolve
such a library, one must consider the relevence of C and the "need" for
such a libray for when it would actually become useful (years from now,
and if it's just one guy doing the development 5 years at least and many
complete overhauls of the architecture).

1.) I don't see the it happening without support from the language
proper. 2.) If the language proper is changed to accomodate elegant
implementation, then it's basically on the path of C++, so when does it
stop?

his compiler supports operator over loading...

When it becomes a C++ but only slightly different? Maybe THAT is
why there are so many libraries in C: the language doesn't have the
supporting mechanisms to allow an elegant implementation that anyone
would want to label as "The Standard C Container Library", so ad-hoc
implementation is actually PREFERRED. Not meaning "write your own",
(though you can), but rather obtain one that is already evolved.

So, just my .02, but I think container libraries for C are outside the
domain of the standard that is C and has been long ago decidedly
relegated to individual developers (companies). Finally, I DO think C
evolution has stopped long ago also and that it is in maintenance mode as
far as the standard goes.

this irritates Jacob, he doesn't believe C has to be frozen like this

 

[Nick Keighley]

and some of them were awful

There should be more than one, and there are. Should there be a
ISO-blessed one, I guess it can't hurt (well it does hurt those in the
business of selling such libraries and it does stagnate evolution of such
things, so maybe it does/did hurt). The STL is so general that it mostly
appeals to, well I don't know whom.
everyone?

Those enamoured with PLs

with whats?

and those
with very large project budgets for sure.

std::vector and std::string seem eminantly usable even in small
programs. What's wrong with the STL? I always thought it was one of C+
+s selling points!



not conforming to the initiator's expectations. To be widely adopted
and maybe even standardised.

[...]  The best that I think any aspiring C container library would
be is some kind of Boost like use.  At the moment, I feel that someone
trying to get a C container library standardized borders on delusions
of grandeur.  30+ years of C and people much smarter than me and still
no standard C container library leaves me with no confidence that it
can be done.  

I agree. But I think the problems are historical and political rather
than technical. I can well imagine C++ going a different route from
the STL and ending up up with a balkanised library.

<snip>

The reasonable person changes himself to fit the world.
The unreasonable person changes the world to fit him.
All human progress has been achieved by the second group.

 

[Nick Keighley]

I actually tried that, back when I was young and foolish!

I was certain *somone* would have!

 

[Malcolm McLean]

std::vector and std::string seem eminantly usable even in small
programs. What's wrong with the STL? I always thought it was one of C+
+s selling points!

I thought that too. In technical terms the performance is a s good as
C structures, and the templated classes are more flexible.

There are two problems.

There's no way of writing a function that accepts a list and having a
reasonable chance that the interface will be accepted, understood, and
convenient for everybody.
The syntax is just a step too far.

I think the STL has in fact played a major role intaking down C++,
simply because of these two facts.

 

[Ian Collins]

I thought that too. In technical terms the performance is a s good as
C structures, and the templated classes are more flexible.

There are two problems.

There's no way of writing a function that accepts a list and having a
reasonable chance that the interface will be accepted, understood, and
convenient for everybody.
The syntax is just a step too far.

Eh?

I think the STL has in fact played a major role intaking down C++,
simply because of these two facts.

Do what?

 

[Malcolm McLean]

Eh?

A "list" is an ordered series of data items.
The generic STL way of taking a list to to take an iterator to the
start and end of the controlled sequence. The problem is that this
mechanism is too difficult, counter-intuitive, or whatever for
everyone to use consistently.

TRy declaring some simple data structures with the STL, in a real but
simple program. Then write the same program in C. You'll soon see the
problem with the STL syntax.

 

[Nick Keighley]

Eh?

void foo( std::list<int>& );

or hide it behind a typedef if templates scare you. But really if you

Do what?

see Template Meta-Programming...
or the diagnostics you get for misusing templates

 

[Nick Keighley]

A "list" is an ordered series of data items.
The generic STL way of taking a list to to take an iterator to the
start and end of the controlled sequence. The problem is that this
mechanism is too difficult, counter-intuitive, or whatever for
everyone to use consistently.

TRy declaring some simple data structures with the STL, in a real but
simple program. Then write the same program in C. You'll soon see the
problem with the STL syntax.-

it becomes more tolerable with time

 

[jacob navia]

Ed a écrit :

People seem to forget history: some set out to improve C 25 years ago and
it resulted in C++. The question becomes, what compromises is one willing
to make on that duplicate path/journey?

Who wants to duplicate that journey?

C++ got completely lost in unmastered complexity traps. The complexity
has grown to such proportions that the creator of the language is unable
to add an apparently simple feature after YEARS of efforts.

"Concepts" anyone?

I do not propose any language changes with this library because
PRECISELY what I want is to prove that much of the complexity
is unnecessary in software development.

The syntax is simple, the speed is roughly the same as the STL,
the size is approximately 1/10th or 1/50th of the STL implementations.

True, there are no templates but a simple program is provided that
replaces templates with no effort.


"half way?" What is "half way?".

No way. I stayed within standard C.

Setting out to Vegas on a whim is not prudent, especially after a night
at the bar. With the studies and justifications and goals and plans
absent, and without a sober state of mind, I see no reason to embark.

GREAT!

Then step aside, do not embark, and keep your prejudices out of this
discussion. You offer no arguments anyway, so you are just contributing
noise.

Bypassing all the practicalities is not a way get people bought-in to the
idea.

???

What did I bypass?

It is not evident that the thousands of list libraries, hash table
libraries written in C could benefit by having a standrad way of
making them inter-operable so that you can replace libraries without
pain?

It may even be dishonest.

What is dishonest is to criticize a proposal without reading
what it proposes.

[snip crap]

 

[jacob navia]

Ian Collins a écrit :

No, it hasn't, the definition of getline is still missing.

That function is defined in fgetline.c line 73.
It is used in strcollection.c line 692 and 696.
The prototype is:
int getline(char **LinePointer,
int *n,
FILE *stream,
ContainerMemoryManager *mm);
Prototype in containers.h line 183.

 

[Richard Kettlewell]

That function is defined in fgetline.c line 73.
It is used in strcollection.c line 692 and 696.
The prototype is:
int getline(char **LinePointer,
int *n,
FILE *stream,
ContainerMemoryManager *mm);
Prototype in containers.h line 183.

Perhaps you could use a different name to 'getline', since that is
already used in Glibc.

 

[Malcolm McLean]

It is not evident that the thousands of list libraries, hash table
libraries written in C could benefit by having a standrad way of
making them inter-operable so that you can replace libraries without
pain?

The problem is that you're just adding one more to the thousands of
libraries out there. Everyone at some point thinks, "linked lists? A
bit of a nuisance to keep on writing that fiddly bit of code to unlink
a node. Can't I knock up a generic linked list library? Hey, maybe
everyone will use it. This should be released as a standard
library ... "

Ypu're not Microsoft, you're not ANSI, you're not Denis Ritchie.
However your advanatage is that you are also the developer of a
compiler. Why not integrate the generic containers intot he syntax of
the language, as an extension? That way a) you can overcome the
difficulty that plagues all these libraries, which is that they a
little bit ugly or difficult to use b) it's a point of difference, a
marketing point, that gives you a higher chance of breaking through
into acceptance c) you can be extremely efficient, no calling memcpy()
for a single pointer or integer.

 

[jacob navia]

Richard Kettlewell a écrit :

Perhaps you could use a different name to 'getline', since that is
already used in Glibc.

I will write a stream container, and that function will be
there. For the time being, note that getline is NOT part
of the specification.

 

[jacob navia]

Malcolm McLean a écrit :

The problem is that you're just adding one more to the thousands of
libraries out there.

No, I am proposing a standard INTERFACE to different libraries.
Not a new library. The sample implementation is there to prove that
the specifications are sound.

 

[jacob navia]

ld a écrit :

this is called "method swizzling" and it's dangerous when applied on
an entire "class".

http://zathras.de/angelweb/blog-method-swizzling-considered-harmful.htm

This reference applies to Objective C "subclassing" or "method swizzling",
as you name it. In Objective C we have a full fledged class hierarchy,
what in C doesn't happen at all. The container library doesn't use
any class hierarchy and all containers are at the same level.

This is quite a difference, since the problems arise when you do
this "swizzling" within a class hierarchy. Since here there isn't
any, the work around proposed in that reference (calling "super")
doesn't apply either.

jacob