C needs a BOOST

[André Gillibert]

Without some changes to the language, how are we going to implement
generic algorithms and data structures? Yes void * is always there,
but that seems a messy and ugly solution.

It's the best solution C has to offer currently.
You may also read jacob navia's proposal about operator overloading and GC.

 

[Malcolm McLean]

jacob navia wrote:



Pure ISO C?

You can devise a resizeable array that will store objects of any size.
The snag is that you need to call memcpy() or loop to perform basic
operations, when most of the time the objects in the array will be pointers,
ints, or something else held in a single register.

So in practise you hand code the array each time.

 

[jacob navia]

C++ didn't have those either, initially. They got tacked on
along the way as agreement was reached on them.

There are far fewer active workers on the C standard than have
been involved with C++, and no major incentive to spend any
significant fraction of the available resources working on
such libraries. Note that the C standards group *has* worked
on several extensions, generally described in Technical
Reports, and adopted complex numbers (with library support)
into the C standard due to demand from the numerical
programming community.


You don't have to reinvent this wheel if you use an already-
developed library that provides what you need. It just won't
be provided automatically with the C compiler, so you have to
arrange to obtain it separately. I have my own library with
support for things like you mentioned, and other experienced
programmers and programming shops most likly do also.

The problem is that there isn't any that is standard.

Everybody has a slightly different one!

 

[James Dennett]

jacob navia wrote:



At the cost of performances, but that's the cost of abstraction, anyway.

And yet the field of generic programming has been built for
years on a foundation of abstraction *not* costing performance,
which is to a large extent realized with C++'s STL and real
current compilers.

There is compile-time cost, but there's no need for runtime
cost for abstraction.

-- James

 

[Flash Gordon]

jacob navia wrote, On 03/10/07 21:50:

Can't you read?
I cite this again then:

I'm using a linked list package that someone else wrote for something
completely different in order to proved a number of unrelated linked
lists in a library used by several other programs. Stragely enough I did
not have to rewrite the linked list module because it was designed to
provide a generic linked list.

In my debugger project there was obviously a list module

Then in the IDE too.

Then, in the compiler there is another one.

Then it seemed stupid to me at spent time making the debugger
use the IDE list package.

Then you should have spent a little longer the first or second time to
write one that was generic enough to be reused, or used some third party
library designed to be generic.

Yes, that happens. Not to you of course.

Well, it happens to me when using a completely different language. I
found that the linked list I wrote in Fortran && on the VAX did not
compile as C and had unacceptable limitations (well, I would have done
if I had access to the code) but I certainly don't have to rewrite
simple generic code as often as you seem to have to.

 

[Flash Gordon]

user923005 wrote, On 03/10/07 21:05:

It would be really nice if C could adopt a really nice algorithms
library like C++'s STL + BOOST.

Opinions? Is keeping the language tiny worth the cost of C
programmers having to constantly reinvent the wheel?

With modern linkers I would have no objection to it. After all, the
linker can just not link in the code if it is not used! Of course, there
might still be linkers around that are not that intelligent.

 

[pete]

It would be really nice if C could adopt a really nice algorithms
library like C++'s STL + BOOST.

The recent "reverse the words in this sentence" problem posted made me
think about it.
It's like 5 lines to do it in C++ because of all the nifty algorithms
that come with the language (I think BOOST is going to get bolted on
to the C++ language like STL did).

It's a lot more work in C than C++. Why doesn't C have stacks,
dequeues, and other common, simple tool sets already in its standard
library?

Opinions? Is keeping the language tiny worth the cost of C
programmers having to constantly reinvent the wheel?

Yes.

Why shouldn't C be more like C++?
Because there is C++.

 

[Eric Sosman]

jacob navia wrote On 10/03/07 16:50,:

Can't you read?
I cite this again then:

So, you're saying that for every serious project they
did, Ritchie, Thompson, Torvalds et al. threw away and
rewrote the C library?

In my debugger project [...]

Is this the same debugger about which you said "Without
[garbage collection], I would never have finished?"

Let's see: You've already described C's lack of
operator overloading as evidence of neglect on the part of
the committee, you've characterized __declspec(naked) as
an important language feature you use "very often," you've
railed at the absence of fixed-point arithmetic, ... Is
there any feature, doodad, or dingbat you think *isn't*
essential to C's survival?

 

[jacob navia]

I wasn't comparing to STL but to GLib.


But we would redo a good part of GLib which you find huge.

No. The list module I wrote makes fir 2380 bytes of code
and 204 bytes of data. Maybe adding some overhead it *could* grow to
4-5K.

GNU software is bloated, but maybe the list module of the
glib can be trimmed to 4-5K.

No, it doesn't work. I tried, but I never succeeded.
C implementations usually generate function importations to their
librairies.

Well, lcc-win32 *can* use the libc from the system, the libc from the
Microsoft compiler and probably the libc of GNU...

e.g. when allocating a big array on stack on Win32, they may call a
function (whose name starts with two underscores or one underscore and a
upper-case letter) that touches the stack at every multiple of 4096 bytes.
Changing the standard library breaks that.

No. If they are shared objects they just have a copy of the C runtime
with them anyway.

Startup code is also likely to call implementation-specific functions or
rely on implementation-specific details of standard library functions.

This is transparent in shared objects.

There are other issues: Implementations are allowed to recognize
standard library functions specially and to provide special
optimizations for them such as inlining. If stack_push is inlined,
relying on a specific memory layout for the stack object, and that
stack_open links to another library, then, bad bad things will occur.

I said:

Link with another library

I did not said:

Use two libraries for lists at the same time!

Note:
I used only ONE exclamation mark.

 

[jacob navia]

jacob navia wrote On 10/03/07 16:50,:

Can't you read?
I cite this again then:

So, you're saying that for every serious project they
did, Ritchie, Thompson, Torvalds et al. threw away and
rewrote the C library?

In my debugger project [...]

Is this the same debugger about which you said "Without
[garbage collection], I would never have finished?"

Let's see: You've already described C's lack of
operator overloading as evidence of neglect on the part of
the committee,

You are misrepresenting everything since you do not want to argue
anymore, just polemic. I do have different opinions about things
here with many people. But I respect the work of the committee and
I have said that several times. I do not agree wit some decisions
and I have expressed my opinion. But I do not accuse anyone of
"neglect" (whatever that means in this context)

you've characterized __declspec(naked) as
an important language feature

Wrong again. I said here that using this low level interface
would be a bad idea, since after a discussion with people
here I saw my error. Contrary to some, I do respect the
arguments of other people and if they look convincing I
change my opinion and openly acknowledge that fact as I did
in this group.

you've
railed at the absence of fixed-point arithmetic, ...

No. I said that the TR that proposed modifications to the standard
would be better done if we give a general solution to the problem
of adding new numeric types.

Is
there any feature, doodad, or dingbat you think *isn't*
essential to C's survival?

You just want to polemic but you are doomed. To start a polemic
you need two. And you are only one.

Yours sincerely

 

[jacob navia]

And yet the field of generic programming has been built for
years on a foundation of abstraction *not* costing performance,
which is to a large extent realized with C++'s STL and real
current compilers.

There is compile-time cost, but there's no need for runtime
cost for abstraction.

-- James

C++ has good ideas. Generic programming is implemented there with
all the bells and whistles you can imagine. This is not the goal
here. The goal would be just a small interface description to
a small library that can represent a MINIMAL interface to lists
stacks, LIFOs hash tables and other commonly used data structures

 

[jacob navia]

Why shouldn't C be more like C++?
Because there is C++.

Nobody is proposing that C should be "more like C++".
The complexity of C++ is at best avoided.

But lists, stacks and hash tables aren't any
C++ invention as far as I remember. Why can't
the C language offer a common interface to use those
commonly used data structures?

 

[Keith Thompson]

user923005 wrote: [...]

Opinions? Is keeping the language tiny worth the cost of C
programmers having to constantly reinvent the wheel?

You don't have to reinvent this wheel if you use an already-
developed library that provides what you need. It just won't
be provided automatically with the C compiler, so you have to
arrange to obtain it separately. I have my own library with
support for things like you mentioned, and other experienced
programmers and programming shops most likly do also.

The problem is that there isn't any that is standard.

Everybody has a slightly different one!

Right, and you have to decide on a single solution *before* you can
add it to the standard.

I think glib attempts to be a general-purpose toolkit that might be
suitable for standardidization. (I don't know enough about it to have
an opinion on whether it should be standardized.) I suspect the
committee wouldn't agree to add a large library to the standard unless
there's at least some consensus on one particular interface.

And I strongly suspect that a library that depends on language
extensions provided by a single compiler wouldn't stand a chance.
You'd *first* have to persuade the committee to adopt the language
extensions. (If the library is sufficiently useful, that might be an
argument in favor of adopting the language extensions.)

 

[jacob navia]

user923005 wrote: [...]
Opinions? Is keeping the language tiny worth the cost of C
programmers having to constantly reinvent the wheel?
You don't have to reinvent this wheel if you use an already-
developed library that provides what you need. It just won't
be provided automatically with the C compiler, so you have to
arrange to obtain it separately. I have my own library with
support for things like you mentioned, and other experienced
programmers and programming shops most likly do also.

The problem is that there isn't any that is standard.

Everybody has a slightly different one!

Right, and you have to decide on a single solution *before* you can
add it to the standard.

I think glib attempts to be a general-purpose toolkit that might be
suitable for standardidization. (I don't know enough about it to have
an opinion on whether it should be standardized.) I suspect the
committee wouldn't agree to add a large library to the standard unless
there's at least some consensus on one particular interface.

And I strongly suspect that a library that depends on language
extensions provided by a single compiler wouldn't stand a chance.
You'd *first* have to persuade the committee to adopt the language
extensions. (If the library is sufficiently useful, that might be an
argument in favor of adopting the language extensions.)

Generic functions like
list = list_add(list,int);
list = list_add(list,double);
list = list_add(list,&CustomerStruct);

would make the library very easy to use. Above all, they
could be extended by the user at any time with

list = list_add(list,&MyNewDataStruct);

P.S. I will look at the glib again.

 

[Ian Collins]

But lists, stacks and hash tables aren't any
C++ invention as far as I remember. Why can't
the C language offer a common interface to use those
commonly used data structures?

Then how come after 30 odd years, it doesn't?

 

[Keith Thompson]

user923005 wrote:

[...]
There are several solutions to your "problem" of genericity.

The first one is the usage of the generic pointer in C: void *

I have written a dynamic table package using that approach. You tell
the software how big your objects are, and then you just use them.
Operator overloading allows you to assign and read the data.

True, the functions return a void pointer that must be casted into
something but that is a minor inconvenience.

You need to convert void* results to some specific pointer type, but
why would you need to cast them?

[...]

I have done just that.
Only flames ensued.

You proposed operator overloading in an article posted to comp.std.c
on 2007-09-05, subject "Operator overloading in C". A lengthy
discussion ensued (Google Groups shows 143 articles in that thread).
In a cursory look through the thread, I see no flames, though I do see
a great deal of constructive criticism. (Telling you "I disagree, and
here's why" is not a flame.)

However, I don't recall you ever proposing a library that provides
stacks and other common data structures. Perhaps I missed it.

But you must be aware that if a proposed library depends on language
features that are not (yet) part of the standard, that's going to be a
considerable obstacle.

You can consider mine. It is working, it has an implementation,
why not looking at it?

Where is it?

(BTW, didn't you say recently that you were going to provide a freely
downloadable Linux version of your compiler? Have you done so?)

 

[jacob navia]

You proposed operator overloading in an article posted to comp.std.c
on 2007-09-05, subject "Operator overloading in C". A lengthy
discussion ensued (Google Groups shows 143 articles in that thread).
In a cursory look through the thread, I see no flames, though I do see
a great deal of constructive criticism. (Telling you "I disagree, and
here's why" is not a flame.)

Look Keith, you are aware of the enthusiastic reception of my ideas
by the c.lang.c "regulars" isn't it?

No, in comp.std.c the situation was much better but I do not
see how that is going to go on. Maybe everyone is just waiting that
I go away

However, I don't recall you ever proposing a library that provides
stacks and other common data structures. Perhaps I missed it.

Where is it?

http://www.q-software-solutions.de/~jacob/proposal.pdf

The same document that proposes the extensions proposes a library
using some of the new features.

Specially look at the string library. The others
use vtables and I think this leads to bad syntax unless there is yet
another extension. I think a better approach would be to use the
generic functions feature and use:

list = list_add(NULL,45);

list = list_add(list,644.887);

list = list_add(list,"Customer Pierre Dupont and Annie Gonzalez");

To access it we would use

#define list_get(list,index, type) *(type *)(list->Data[index]);

or similar.

(BTW, didn't you say recently that you were going to provide a freely
downloadable Linux version of your compiler? Have you done so?)

Yes, I did it and you can download it from
http://www.q-software-solutions.de/products/lcc-linux32/index.shtml

Please be patient. I have worked a lot in it but it still has a lot of
rough edges. All extensions should be working except
__try/__except.

I think I will be using wine's implementation of that as a guide.

But use the windows version, it is more tested. In august, the windows
version went over the *half million* downloads mark!

 

[Chris McDonald]

Generic functions like
list = list_add(list,int);
list = list_add(list,double);
list = list_add(list,&CustomerStruct);

would make the library very easy to use. Above all, they
could be extended by the user at any time with

Could you please clarify these?

Did you mean to add at the head, or at the tail, or somewhere in the
middle, that the list remain sorted by some user-specified sorting
function, and should duplicates be permitted or removed?

Oh, never mind, I'll just write the 10 line function that I need and
understand.

 

[jacob navia]

Then how come after 30 odd years, it doesn't?

Because C++ started to grow as "the better C" and
C was thrown into the bin "old and obsolete".

Dozens of C++ books were written that as a matter of habit wrote
in their "Introduction to C++" how BAD the C language was, and
how WONDERFUL the new language was, compared to that OLD C, etc.

The C community reacted with a tendency to look into the past,
and it "enshrined" their language resisting any change
of it at all. C99 was the result: a standard that makes
small improvements (VLAs, complex numbers, and others)
but leaves the mess of the very old C library design intact.

The C++ guys just laughed at it, and gcc and Microsoft decided
to just drop C. Gcc hasn't still 8 years later finished the
C99 implementation, they do not participate into any standard
body (even if they could). Microsoft has participated in some
proposals (the safer C Technical Report) but in fact has
dropped C as a development language too.

C is then seen as an old and obsolete language by most
programmers. Its main use should be in small circuit
boards where there is no space for a language like
C++. When those circuit boards disappear, C will disappear
with them. It will remain (like COBOL) in a frozen state
for the biggest part of this century as the software
written in C is slowly rewritten in other, more
modern languages.

So the story goes.

But I think that C, *precisely* because of its small size, it
is *better* adapted for the software of the future. Yes, I have
proposed some changes to the syntax, fairly minor. They are
essentially:

o operator overloading
o generic functions

This would allow to write a small standard library that would
allow people to use higher level data structures with easy
within a common framework.

What is crucial is that the library has a small memory footprint.
Not in RAM of course, but in HUMAN memory footprint. This means that
the library is easy to remember and use, that it has a consistent
naming, and that it is kept as simple as possible.

Software has a tendency to bloat forever. But in software (as in
hardware) smaller means more efficient and less wasteful. Many
languages have started that try to be simpler than C++. But
there is NO need to go very far. C has retained its simplicity
and is well adapted to the future precisely because it is
small.

 

[Keith Thompson]

Nobody is proposing that C should be "more like C++".

[...]

Sure you are.

You're not proposing that C should be just like C++, but you're
certainly proposing that it should be closer to C++ than it is now.
(I'm not saying that's necessarily a bad thing.)