C needs a BOOST

[user923005]

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?

[André Gillibert]

user923005 wrote:

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

How would you implement that in C?
Is there any solution simplier than transforming C into C++?
(GC and operator overloading proposed by jacob navia won't provide generic
algorithms).

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

Keeping the language small makes C different from C++, and that's why, C
can still be better than C++ for some projects.
On the other hand, transforming C into C++ would be pointless, as it would
make the C and C++ language duplicates.

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?

Propose an implementable solution. Ideally, with several successful
real-world implementations.
Then, we may consider your offer.

--
If you've a question that doesn't belong to Usenet, contact me at
<ta*****************@yahoDELETETHATo.fr>

[jacob navia]

André Gillibert wrote:

user923005 wrote:

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

How would you implement that in C?
Is there any solution simplier than transforming C into C++?
(GC and operator overloading proposed by jacob navia won't provide
generic algorithms).

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.

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

Keeping the language small makes C different from C++, and that's why, C
can still be better than C++ for some projects.

This is an error. Keeping the language in this state makes the language
impossible to use for any serious software development
unless your project is big enough to warrant rewriting the
C library and adding stacks, lists, etc etc at each project!

On the other hand, transforming C into C++ would be pointless, as it
would make the C and C++ language duplicates.

Yes. What I am proposing is nothing of the sort.

I am just proposing using operator overloading, a very common
feature found in almost all languages including FORTRAN, Visual Basic,
C# C++, and what have you!

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

Propose an implementable solution. Ideally, with several successful
real-world implementations.

I have done just that.
Only flames ensued.

Then, we may consider your offer.

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

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Clever Monkey]

user923005 wrote:

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?

Why does this have to be part of the language? There are plenty of
third-party APIs that give you this.

There are plenty of reasons to keep a language small, and let the
implementors provide solutions for their customers.

[jacob navia]

user923005 wrote:

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?

We had a discussion about this a few weeks ago.
I proposed several minor modifications to the language to be able to
access containers, stacks queues, lists and other objects by using
an uniform interface. Please see the thread "Operator overloading in C"
in comp.std.c, started by myself on September 5th.

You can download an implementation of those ideas at
http://www.cs.virginia.edu/~lcc-win32
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Malcolm McLean]

"user923005" <dc*****@connx.comwrote in message

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

It is generally slightly easier to implement a structure from scratch than
to use someone else's interface. In the case of the liked list, queue and
stack it is unclear whether this says something good or something bad about
C.

For more complicated structures it seems clear that you shouldn't have to do
them yourself. Plenty of code is publically available, some of it written by
myself. However it always seems to define bool, or take control of your
main, or demand the filling in of complex structures to get the system
operational, or doing at least something unspeakable. The code portion of my
website is not especially popular, with the exception only of the Basic
interpreter.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[jacob navia]

Clever Monkey wrote:

user923005 wrote:

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

Why does this have to be part of the language? There are plenty of
third-party APIs that give you this.

Each one different than the other. There isn't a STANDARD way of doing a
list, so you have to construct a list each time you want to use one!

But we have discussed this several times, and nothing ever changes.

gets() is still there and will stay with us at least till 2019.

There are plenty of reasons to keep a language small, and let the
implementors provide solutions for their customers.

Most of the time this means that each developer is forced to write
a list handling stuff at each application.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[jacob navia]

Malcolm McLean wrote:

"user923005" <dc*****@connx.comwrote in message

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

It is generally slightly easier to implement a structure from scratch
than to use someone else's interface. In the case of the liked list,
queue and stack it is unclear whether this says something good or
something bad about C.

It just says that you must reinvent the wheel at each
application.

Great Malcolm.

For more complicated structures it seems clear that you shouldn't have
to do them yourself. Plenty of code is publically available, some of it
written by myself. However it always seems to define bool, or take
control of your main, or demand the filling in of complex structures to
get the system operational, or doing at least something unspeakable. The
code portion of my website is not especially popular, with the exception
only of the Basic interpreter.

Wouldn't it be a good idea to propose an STL clone?

It *can* be done in C!!!

That would be an interesting undertaking no?

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Eric Sosman]

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

André Gillibert wrote:

>>Keeping the language small makes C different from C++, and that's why, C
can still be better than C++ for some projects.

This is an error. Keeping the language in this state makes the language
impossible to use for any serious software development
unless your project is big enough to warrant rewriting the
C library and adding stacks, lists, etc etc at each project!

Since C is impossible to use for serious software
development, one wonders why so many programmers spent
so many years writing so much non-serious (comic?)
software. Ritchie, Thompson, heck, even Torvalds have
just been clowning around, right?

--
Er*********@sun.com

[jacob navia]

Eric Sosman wrote:

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

>André Gillibert wrote:

>>Keeping the language small makes C different from C++, and that's why, C
can still be better than C++ for some projects.

This is an error. Keeping the language in this state makes the language
impossible to use for any serious software development
unless your project is big enough to warrant rewriting the
C library and adding stacks, lists, etc etc at each project!

Since C is impossible to use for serious software
development, one wonders why so many programmers spent
so many years writing so much non-serious (comic?)
software. Ritchie, Thompson, heck, even Torvalds have
just been clowning around, right?

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

>unless your project is big enough to warrant rewriting the
C library and adding stacks, lists, etc etc at each project!

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.

Yes, that happens. Not to you of course.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[André Gillibert]

jacob navia wrote:

There are several solutions to your "problem" of genericity.
The first one is the usage of the generic pointer in C: void *

At the cost of performances, but that's the cost of abstraction, anyway.
If that's all user923005 wants, he can use GLib or other C librairies.

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

I looked at it.
--
If you've a question that doesn't belong to Usenet, contact me at
<ta*****************@yahoDELETETHATo.fr>

[jacob navia]

André Gillibert wrote:

jacob navia wrote:

>There are several solutions to your "problem" of genericity.
The first one is the usage of the generic pointer in C: void *

At the cost of performances, but that's the cost of abstraction, anyway.
If that's all user923005 wants, he can use GLib or other C librairies.

I tried to use the Glib, but then I was confronted with a HUGE package
that I would have to port everywhere and I could not control
at all.

It would be much better for everybody that we had a standard
interface like in C++ and then use a standard library!
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[André Gillibert]

jacob navia wrote:

I tried to use the Glib, but then I was confronted with a HUGE package
that I would have to port everywhere and I could not control
at all.

It would be much better for everybody that we had a standard
interface like in C++ and then use a standard library!

In that case, you must expect that this HUGE package be bundled with every
C implementation... I hardly can see why C implementors would produce
better code than GNU's guys.

Actually, with C++'s STL, I've seen that most implementations have an
incredibely low QOI. Consequently, I've always to use an external
implementation (STLPort) which has far less bugs, and produces much better
code.

I don't see why the STL problem wouldn't be reproduced for C.

Unfortunately, C doesn't support namespaces, so it's not easy to replace
the standard library with a different implementation.

With the C++ STL experience I got, I think it's important to get the
standard library small, mainly containing components that cannot easily
and efficiently be implemented in pure standard C.

Otherwise, you're sure to get all the bloat with every C implementation.
Cross-compiler linking will result in linking issues or duplication of the
code bloat.

--
If you've a question that doesn't belong to Usenet, contact me at
<ta*****************@yahoDELETETHATo.fr>

[Douglas A. Gwyn]

user923005 wrote:

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?

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.

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.

If you find a good example that you would like standardized,
propose it during the next round of revision of the C
standard. It needs substantial user experience or it is
likely to be considered too risky to force it upon everybody.

[santosh]

user923005 wrote:

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

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.

<snip>

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

Constantly? A library like GLib can be ported to most architectures, and
where it's not practical to port to, a Standardised library is going to
face equally tough problems.

[santosh]

jacob navia wrote:

<snip>

Wouldn't it be a good idea to propose an STL clone?

It *can* be done in C!!!

Pure ISO C?

[Ian Collins]

user923005 wrote:

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?

Alex Stepanov's STL became part of the C++ standard library because it
was there, it filled a need and became extremely poplar. There were
competing libraries, but through the process of natural selection, the
STL became the most popular. So it became a de facto standard before it
was standardised. The same thing is happening with parts of boost.

Which raises the question why hasn't anyone written such a popular
library for C? C has been around a decade or more longer than C++,
plenty of time for a "killer library" to appear, but it hasn't.

My conclusion has to be that the demand isn't there.

By the way, does the C standard committee have an active library group?

--
Ian Collins.

[jacob navia]

André Gillibert wrote:

jacob navia wrote:

>I tried to use the Glib, but then I was confronted with a HUGE package
that I would have to port everywhere and I could not control
at all.

It would be much better for everybody that we had a standard
interface like in C++ and then use a standard library!

In that case, you must expect that this HUGE package be bundled with
every C implementation... I hardly can see why C implementors would
produce better code than GNU's guys.

Because C's implementation should be SUBSTANTIALLY smaller,
giving just bare bones usage and not all the blat that comes
with the STL

Today at work I was with another coworker debugging a problem,
and when he loaded a C++ module he said:

Gosh this module uses the STL, and I can't stand it jacob. Nobody
knows exactly what the hell is doing!

I think we have a HUGE market there :-)

Actually, with C++'s STL, I've seen that most implementations have an
incredibely low QOI. Consequently, I've always to use an external
implementation (STLPort) which has far less bugs, and produces much
better code.

I don't see why the STL problem wouldn't be reproduced for C.

Because we would NOT redo the STL of course!

We need just a small set of operations and some generic functions.

Unfortunately, C doesn't support namespaces, so it's not easy to replace
the standard library with a different implementation.

There is no NEED for namespaces! We could just LINK with a different
implementation! The standard defines a C library, and you can
use different versions of the library and different implementations
just by relinking your code!

With the C++ STL experience I got, I think it's important to get the
standard library small, mainly containing components that cannot easily
and efficiently be implemented in pure standard C.

Yes. SMALL! Like C. And the point of is that SMALL is better in
software. Like smaller integrated circuits that are MORE efficient
than bulky ones, SMALL software components are more mangeable and
easy to understand and USE!!!!!!!

Otherwise, you're sure to get all the bloat with every C implementation.
Cross-compiler linking will result in linking issues or duplication of
the code bloat.

Why? It would be just another LIBRARY

--If you've a question that doesn't belong to Usenet, contact me at
<ta*****************@yahoDELETETHATo.fr>

A+
:-)

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[André Gillibert]

jacob navia wrote:

André Gillibert wrote:

>every C implementation... I hardly can see why C implementors would
produce better code than GNU's guys.

Because C's implementation should be SUBSTANTIALLY smaller,
giving just bare bones usage and not all the blat that comes
with the STL

I wasn't comparing to STL but to GLib.

Because we would NOT redo the STL of course!

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

>Unfortunately, C doesn't support namespaces, so it's not easy to
replace the standard library with a different implementation.

There is no NEED for namespaces! We could just LINK with a different
implementation! The standard defines a C library, and you can
use different versions of the library and different implementations
just by relinking your code!

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

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.
Startup code is also likely to call implementation-specific functions or
rely on implementation-specific details of standard library functions.

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.

>

>With the C++ STL experience I got, I think it's important to get the
standard library small, mainly containing components that cannot easily
and efficiently be implemented in pure standard C.

Yes. SMALL! Like C. And the point of is that SMALL is better in
software. Like smaller integrated circuits that are MORE efficient
than bulky ones, SMALL software components are more mangeable and
easy to understand and USE!!!!!!!

Please, don't use more than one exclamation mark at once.
From Terry Pratchett's Masquerade:
| And all those exclamation marks, you notice? Five? A sure sign
| of someone who wears his underpants on his head.

>Otherwise, you're sure to get all the bloat with every C implementation.
Cross-compiler linking will result in linking issues or duplication of
the code bloat.

Why? It would be just another LIBRARY

At least on Win32, most implementations don't share their standard
library, believe me.
Which means that, when linking an application or DLL compiled with
implementation A to a DLL compiled with implementation B, the final code
uses the libraries from both implementations, which, in average,
multiplies the library code bloat by a factor two. If the library is
small, it's acceptable. If it's large, it becomes less acceptable.

On other platforms, there's often a better cooperation.
--
If you've a question that doesn't belong to Usenet, contact me at
<ta*****************@yahoDELETETHATo.fr>

[André Gillibert]

santosh wrote:

jacob navia wrote:

<snip>

>Wouldn't it be a good idea to propose an STL clone?

It *can* be done in C!!!

Pure ISO C?

Yes.

--
If you've a question that doesn't belong to Usenet, contact me at
<ta*****************@yahoDELETETHATo.fr>

[André Gillibert]

santosh wrote:

user923005 wrote:

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

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.

--
If you've a question that doesn't belong to Usenet, contact me at
<ta*****************@yahoDELETETHATo.fr>

[Malcolm McLean]

"santosh" <sa*********@gmail.comwrote in message
news:fe**********@aioe.org...

jacob navia wrote:

<snip>

>Wouldn't it be a good idea to propose an STL clone?

It *can* be done in C!!!

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.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[jacob navia]

Douglas A. Gwyn wrote:

user923005 wrote:

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

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.

>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!
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[James Dennett]

André Gillibert wrote:

jacob navia wrote:

>There are several solutions to your "problem" of genericity.
The first one is the usage of the generic pointer in C: void *

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

[pete]

user923005 wrote:

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

--
pete

[Eric Sosman]

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

Eric Sosman wrote:

>>jacob navia wrote On 10/03/07 16:31,:

>>>André Gillibert wrote:
Keeping the language small makes C different from C++, and that's why, C
can still be better than C++ for some projects.

This is an error. Keeping the language in this state makes the language
impossible to use for any serious software development
unless your project is big enough to warrant rewriting the
C library and adding stacks, lists, etc etc at each project!

Since C is impossible to use for serious software
development, one wonders why so many programmers spent
so many years writing so much non-serious (comic?)
software. Ritchie, Thompson, heck, even Torvalds have
just been clowning around, right?

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

>unless your project is big enough to warrant rewriting the
>C library and adding stacks, lists, etc etc at each project!

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?

--
Er*********@sun.com

[jacob navia]

André Gillibert wrote:

jacob navia wrote:

>André Gillibert wrote:

>>every C implementation... I hardly can see why C implementors would
produce better code than GNU's guys.

Because C's implementation should be SUBSTANTIALLY smaller,
giving just bare bones usage and not all the blat that comes
with the STL

I wasn't comparing to STL but to GLib.

>Because we would NOT redo the STL of course!

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.

>>Unfortunately, C doesn't support namespaces, so it's not easy to
replace the standard library with a different implementation.

There is no NEED for namespaces! We could just LINK with a different
implementation! The standard defines a C library, and you can
use different versions of the library and different implementations
just by relinking your code!

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 at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[jacob navia]

Eric Sosman wrote:

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

>Eric Sosman wrote:

>>jacob navia wrote On 10/03/07 16:31,:

André Gillibert wrote:
Keeping the language small makes C different from C++, and that's why, C
can still be better than C++ for some projects.
This is an error. Keeping the language in this state makes the language
impossible to use for any serious software development
unless your project is big enough to warrant rewriting the
C library and adding stacks, lists, etc etc at each project!
Since C is impossible to use for serious software
development, one wonders why so many programmers spent
so many years writing so much non-serious (comic?)
software. Ritchie, Thompson, heck, even Torvalds have
just been clowning around, right?

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

> >unless your project is big enough to warrant rewriting the
C library and adding stacks, lists, etc etc at each project!

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
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[jacob navia]

James Dennett wrote:

André Gillibert wrote:

>jacob navia wrote:

>>There are several solutions to your "problem" of genericity.
The first one is the usage of the generic pointer in C: void *

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

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
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[jacob navia]

pete wrote:

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

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

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

<snip>

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.
--
Flash Gordon

[Keith Thompson]

jacob navia <ja***@nospam.orgwrites:

Douglas A. Gwyn wrote:

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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[jacob navia]

Keith Thompson wrote:

jacob navia <ja***@nospam.orgwrites:

>Douglas A. Gwyn wrote:

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

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Ian Collins]

jacob navia wrote:

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

--
Ian Collins.

[Keith Thompson]

jacob navia <ja***@nospam.orgwrites:

André Gillibert wrote:

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

[...]

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

Propose an implementable solution. Ideally, with several successful
real-world implementations.

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.

>Then, we may consider your offer.

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?)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Chris McDonald]

jacob navia <ja***@nospam.orgwrites:

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

--
Chris.

[jacob navia]

Ian Collins wrote:

jacob navia wrote:

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

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.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Keith Thompson]

jacob navia <ja***@nospam.orgwrites:

pete wrote:

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

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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[jacob navia]

Chris McDonald wrote:

jacob navia <ja***@nospam.orgwrites:

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

At the tail

or somewhere in the

middle,

that would be

list_insert

that the list remain sorted by some user-specified sorting

function,

that would be

list_add_sorted

and should duplicates be permitted or removed?

A set of flags can be specified at list creation as
to how to insert things (with or without duplicates,
set/unset a sorting function that defaults to memcmp
and some options) but basically you need just little
of all that.

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

10 lines for the specs you yourself specified above?

I am giving just examples of generic functions that could be
used to

list_add
vector_add
hash_add

giving a generic, easy to remember interface. That was my point.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Chris McDonald]

jacob navia <ja***@nospam.orgwrites:

>Chris McDonald wrote:

>jacob navia <ja***@nospam.orgwrites:

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

>At the tail

Ohhh, so you don't mean 'list', you mean 'queue'?

Gee, this agreement can be tricky can't it?

--
Chris.

[Keith Thompson]

jacob navia <ja***@nospam.orgwrites:
[...]

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.

Ok, but C doesn't have generic functions, and you can't write a
function that takes either an int, a double, or a pointer as its
second argument.

What exactly are you proposing?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[jacob navia]

Keith Thompson wrote:

jacob navia <ja***@nospam.orgwrites:

>pete wrote:

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

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

In the surface yes.

Operator overloading exists in many other languages than C++.
Fortran, Visual Basic, C#... many.

Overloaded functions that dispatch according to the type of the
arguments exist in other languages too.

But even if I use the same syntax, the simplicity of the language
is preserved. That's why I was completely opposed to introducing
constructors for instance, remember?

This limited set of changes makes the language more easy to
use (syntax sugar makes coffee easier to drink ) without changing
any of its fundamental concepts.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[jacob navia]

Chris McDonald wrote:

jacob navia <ja***@nospam.orgwrites:

>Chris McDonald wrote:

>>jacob navia <ja***@nospam.orgwrites:

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,

>At the tail

Ohhh, so you don't mean 'list', you mean 'queue'?

Gee, this agreement can be tricky can't it?

Lists (as you probably know) can be used to implement
other data structures.

A stack can be implemented with a list. Is it a stack or a list?

If you want to discuss, go ahead. But if you just
want to prove that you know more of the subject and are much clever
than me...

PLEASE bring YOUR proposal

:-)
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Chris McDonald]

jacob navia <ja***@nospam.orgwrites:

>.... But if you just
want to prove that you know more of the subject and are much clever
than me...

No, I'll leave that to the many others here.

I had better not troll the troll.

--
Chris.

[Keith Thompson]

jacob navia <ja***@nospam.orgwrites:

Keith Thompson wrote:

>>>Propose an implementable solution. Ideally, with several successful
real-world implementations.
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.)

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 :-)

[...]

You might have better luck if you concentrated on discussing your
ideas rather than complaining about people's reactions to them.

You made your proposal in comp.std.c. You claimed above that "Only
flames ensued"; that just isn't true.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Eric Sosman]

jacob navia wrote:

pete wrote:

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

.... says the proponent of operator overloading, generic
functions, and garbage collection.

"The true test of a first-rate mind is the ability to
hold two contradictory ideas at the same time." -- F.S.F.

--
Eric Sosman
es*****@ieee-dot-org.invalid

[Ian Collins]

jacob navia wrote:

Ian Collins wrote:

>jacob navia wrote:

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

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 lack of library update is C99 probably reflect the lack of de facto
or even popular extensions.

>
Software has a tendency to bloat forever. But in software (as in
hardware) smaller means more efficient and less wasteful.

The size of the language isn't necessarily reflected in the size of the
resulting executable.

--
Ian Collins.

[Richard Heathfield]

André Gillibert said:

<snip>

You may also read jacob navia's proposal about operator overloading and
GC.

The problem with that idea is that Mr Navia is notorious in comp.lang.c for
not understanding the C language anything like as well as an implementer
ought to understand it, not understanding how to react properly to
criticism, and not understanding how not to libel other people. These
issues do not make it easy to hold rational discussions.

If you have any proposals from people whose opinions are widely respected
in the C community (e.g. Chris Torek, Steve Summit, or Lawrence Kirby, to
name but a few), I think you might find that such proposals would get a
wider readership and a proper debate.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

jacob navia said:

<snip>

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, my dear chap, that's only because they don't know you as well as we
do.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Chris Thomasson]

"user923005" <dc*****@connx.comwrote in message
news:11**********************@y42g2000hsy.googlegr oups.com...

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?

You can program your collections in C. For instance, a simple "inline" LIFO
linked-list:

http://appcore.home.comcast.net/misc/macro-slist-c.html

This is not rocket-science...