The C Containers Library

[W Karas]

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 toallow 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.

 

[Alan Curry]

Le 27/07/12 00:29, Alan Curry a écrit :

Have you read the RFCs?

Lots of them! RFCs are notably not published by ISO. They're more
readable, and also more redistributable (you can actually download the
official RFCs, not just drafts).

They are written in a language anybody can understand. And they have
less ambiguities than the C standard.

My point is that even if you write specifications in a lawyer friendly
language, they do not get better because of that. It is just that the
people that can understand what they mean are less numerous since
now you need to read standardese and correctly interpret it.

Yes, let's transfer control over the C language to IETF and it'll be
better

 

[Rui Maciel]

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.

You are attributing an unwarranted importance to a set of generic containers
while ignoring every other feature that is provided by C++. Even if the STL
wasn't added to the C++ standard, C++'s support for generic programming
would make it possible that anyone with a basic data structures course (or
even intro to programming) could easily develop their own generic data
structures. In fact, that's something that, in spite of the STL, some
people still do. In addition, some popular C++ toolkits still rely on their
own generic containers instead of the STL. So, I believe it is safe to say
that STL's role in decisions regarding migrations from C to C++ is a bit
overblown.


Rui Maciel

 

[Malcolm McLean]

בת×ריך ×™×•× ×©×™×©×™, 27 ביולי 2012 19:28:19 UTC+1, מ×ת W Karas:

On Friday, July 27, 2012 10:25:57 AM UTC-4, James Kuyper wrote:

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 veryimportant to maintaining C as a viable alternative. So it should not be that big of a challenge.

When STL first came out I thought that maybe it was the end of C. The STL containers did provide runtime performance and encapsulation that you had tohandtune C to match.
But actually the result was the reverse. I think it was because STL made the syntax for just declaring an array and stepping through it too cumbersome.. That was the point at whcih people stopped switching from C to C++, and started moving from C++ to other languages. C++ had a huge user base behind it and is still a popular language. But ever since STL it's been in decline..
I'm current programming under Qt. However I've deliberately written all thenon-GUI elements of the program in C. Even the C++ elements aren't really C++, because Qt preprocesses them to make the signals and slots mechanism work. C++ doesn't provide the flexiblity to do this natively.

 

[Ben Bacarisse]

בת×ריך ×™×•× ×©×™×©×™, 27 ביולי 2012 19:28:19 UTC+1, מ×ת W Karas:
When STL first came out I thought that maybe it was the end of C. The
STL containers did provide runtime performance and encapsulation that
you had to handtune C to match.

But actually the result was the reverse. I think it was because STL
made the syntax for just declaring an array and stepping through it
too cumbersome.

What's so cumbersome? For example:

vector<int> ia = {1, 2, 3, 4, 5, 6, 7, 8};
for (int i = 0; i < ia.size(); i++)
cout << ia << "\n";

The C version is *more* cumbersome in my option. If you code the size
of the array separately you can avoid the sizeof ia / sizeof *is idiom,
but that make the code more fragile.

I deliberately used a Cish loop and access method rather the C++'s
neater "for each" construct:

for (int e: ia)
cout << e << "\n";

to make the comparison clearer.

<snip>

 

[lawrence.jones]

By the way the proposal was accepted for discussion in the next meeting
of the committee at Portland, October 22th to October 26th.

That's great, but I can tell you from experience that unless there's
somebody at the meeting to talk to the proposal and commit to following
up, that discussion is apt to be short and not very productive.
--
Larry Jones

I always send Grandma a thank-you note right away. ...Ever since she
sent me that empty box with the sarcastic note saying she was just
checking to see if the Postal Service was still working. -- Calvin

 

[W Karas]

W Karas wrote:









You are attributing an unwarranted importance to a set of generic containers

while ignoring every other feature that is provided by C++. Even if the STL

wasn't added to the C++ standard, C++'s support for generic programming

would make it possible that anyone with a basic data structures course (or

even intro to programming) could easily develop their own generic data

structures. In fact, that's something that, in spite of the STL, some

people still do. In addition, some popular C++ toolkits still rely on their

own generic containers instead of the STL. So, I believe it is safe to say

that STL's role in decisions regarding migrations from C to C++ is a bit

overblown.





Rui Maciel

Hmm, seems your underlying principle here is that a library that can be written in portable Standard C should not be a Standard library. I think thiswould make some sense if standard compliance were a simple yes/no thing, as this would be a barrier for the availability of C compilers on new architectures. But a compiler provider can simply market their compiler as "C Standard-compliant, except for xyz".

Or perhaps you are saying that the error-prone lack of type-checking in a Ctype-independent container library makes such a beast too risky to use. While there is validity to that point of view, the beast has already been let out of the cage by the presence of void pointers in the language.

Also note that your argument would imply that qsort() should not be a Standard library function.

 

[jacob navia]

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

 

[jacob navia]

Le 28/07/12 23:46, (e-mail address removed) a écrit :

That's great, but I can tell you from experience that unless there's
somebody at the meeting to talk to the proposal and commit to following
up, that discussion is apt to be short and not very productive.

I am saving money but this will cost me about US$ 2000 in air plane
tickets, hotel costs, etc. I plan to stay only for a few days but even
with that it will very expensive...

jacob

 

[Ansel]

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.


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.

 

[jacob navia]

Le 29/07/12 06:08, Ansel a écrit :

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:

jacob

 

[Alan Curry]

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.

 

[Noob]

That's great, but I can tell you from experience that unless there's
somebody at the meeting to talk to the proposal and commit to following
up, that discussion is apt to be short and not very productive.

I was wondering how often the WG14 committee met in Europe.

http://www.open-std.org/jtc1/sc22/wg14/www/meetings

 

[jacob navia]

Le 29/07/12 09:43, Alan Curry a écrit :

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.

 

[Rui Maciel]

Hmm, seems your underlying principle here is that a library that can be
written in portable Standard C should not be a Standard library.

<snip/>

No, it isn't. What I pointed out was that other features weigh more on the
decision to migrate to C++ than the STL, which might be completely
irrelevant in this regard.


Rui Maciel

 

[Nick Keighley]

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.

Personally I find the C Standard very clear and readable. (Take a
look
at the C++ or the ultimate horror- Algol-68)

James is saying that you aren't capable of writing in the legalistic
style of an ISO standard.

Just reading the stuff is tedious. Writing it must be even more so.

probably yes

 

[Nick Keighley]

Le 29/07/12 09:43, Alan Curry a écrit :

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 saythat.
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.

actually it uses LGPL which is less restrictive

 

[Alan Curry]

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.

Yes, it has major problems. But it also has millions of installations
and thousands of programmers are already familiar with it.

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

I don't see how this matters. Was there a public domain implementation
of all the C89 functions before they were standardized?

My point would be equally valid if I used the Microsoft equivalent to
GLib as an example, but I don't know what the Microsoft equivalent to
GLib is. (I assume they have a similar library of non-standard utility
functions with trees and hash tables and such.)

 

[jacob navia]

Le 29/07/12 19:27, Alan Curry a écrit :

Yes, it has major problems. But it also has millions of installations
and thousands of programmers are already familiar with it.

So, you propose that the standard accepts something hat has "major
problems" as you say just because it is used in GTK+ ?


What is the logic behin d that? I do not see any.

I don't see how this matters. Was there a public domain implementation
of all the C89 functions before they were standardized?

My point would be equally valid if I used the Microsoft equivalent to
GLib as an example, but I don't know what the Microsoft equivalent to
GLib is. (I assume they have a similar library of non-standard utility
functions with trees and hash tables and such.)

Microsoft has abandonned any development in C or C++ since the adoption
of the C# language. Even Visual Basic now runs in the virtual .net
machine, as do many other languages that are just different language
front ends for the .net VM.

Of course there isn't any official announcement of this but you can
see where the Microsoft emphasis is just by reading between the lines

There isn't any new versions of the SDK since several years now, the
developments of the C++ wrappers for the windows API has ceased, and
in general Microsoft is going in the direction of "managed" C++ if
at all.

So, from that side there isn't anything.

From the linux/gnu side GTK+ uses the glib yes, but I do not know of
many major software that uses that stuff OUTSIDE gtk+. I would be
interested to know if there is any. Can you name a few?

Thanks

 

[Keith Thompson]

Yes, it has major problems. But it also has millions of installations
and thousands of programmers are already familiar with it.

And as far as I can tell, glib has no function called "xmalloc".
Perhaps it was in an earlier version?