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]

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.

 

[jacob navia]

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.

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!

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?

 

[Clever Monkey]

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]

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]

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.

 

[Malcolm McLean]

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.

 

[jacob navia]

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?

 

[Eric Sosman]

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

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?

 

[jacob navia]

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

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:

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.

 

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

 

[jacob navia]

jacob navia wrote:



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!

 

[Douglas A. Gwyn]

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.

 

[André Gillibert]

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.

 

[santosh]

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.

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:

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

It *can* be done in C!!!

Pure ISO C?

 

[Ian Collins]

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?

 

[jacob navia]

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
<[email protected]>

A+

 

[André Gillibert]

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.

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.

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.

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.

 

[André Gillibert]

jacob navia wrote:



Pure ISO C?

Yes.