C needs a BOOST

[Ed Jensen]

It what way does that contradict my conclusion?

The demand was, and still is, there; however, since the powers-that-be
aren't evolving C to meet those demands, developers simply end up
leaving the language.

 

[Malcolm McLean]

C99 has required years to implement.

Has taken years to implement.

 

[Malcolm McLean]

That's a matter of taste. Personally, given a language that supports
operator overloading, I have no problem with using "+" for string
concatenation. The fact that it's not commutative just doesn't bother
me. The intended meaning of
"hello" + " " + "world"
seems perfectly obvious. It's a convenient notation; mathematical
purity isn't required.

The problem is that this doesn't arise too often. The actual example you
posed would always be rendered "hello world", for example, so really it is

char *audience;

"hello " + audience;

Most often you want to embed numbers in strings you create on the fly,
because usually the output will be numerical.

"hello " + audience ", you have " + ticks + "seconds on your account".

Unfortuately then

"hello " + audience + "time left " + hours + minutes + "\n";

isn't clear.

 

[Tor Rustad]

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?

What about requiring that implementations use a stable algorithm for
qsort() first?

From the systems programmers perspective, I think they want the C to
stay small and simple language. I can remember how Linus flamed, on the
suggestion of adding strlcpy/strlcat to glibc. In his view, glibc was
already too bloated and should instead remove stuff.

IMO, the OO way of designing ADT is superior. If extending C's abilities
in this regard, the natural path to my mind, would rather be to pull in
some C++ features, like class. Going down that road, you want operator
overloading, templates etc. etc. => use C++

--
Tor <torust [at] online [dot] no>

"There are two ways of constructing a software design. One way is to
make it so simple that there are obviously no deficiencies. And the
other way is to make it so complicated that there are no obvious
deficiencies"

 

[jacob navia]

The demand was, and still is, there; however, since the powers-that-be
aren't evolving C to meet those demands, developers simply end up
leaving the language.

EXACTLY.

 

[Keith Thompson]

C99 has required years to implement. A parser is not a compiler. It
is part of a compiler.

[...]

A parser is not a front end. It is part of a front end.

 

[Keith Thompson]

The problem is that this doesn't arise too often. The actual example
you posed would always be rendered "hello world", for example, so
really it is

char *audience;

"hello " + audience;

Most often you want to embed numbers in strings you create on the fly,
because usually the output will be numerical.

"hello " + audience ", you have " + ticks + "seconds on your account".

That "," should be "+", yes?

Unfortuately then

"hello " + audience + "time left " + hours + minutes + "\n";

isn't clear.

So you provide a function that converts an integer to a string:

"hello " + audience + "time left " + image(hours) + image(minutes) + "\n";

 

[Malcolm McLean]

So you provide a function that converts an integer to a string:

"hello " + audience + "time left " + image(hours) + image(minutes) + "\n";

Now you've introduced a requirement for automatic garbage collection.
It's the approach I used in MiniBasic, but then it was never sold as a fast,
low-level language.

 

[Keith Thompson]

Ok Mr Kenneth Thompson

Hey, I've been mistaken for Ken Thompson before. ("Are you *the*
Keith Thompson, the Unix guru?" Well, sort of, but not the one you're
thinking of.)

 

[Ian Collins]

The demand was, and still is, there; however, since the powers-that-be
aren't evolving C to meet those demands, developers simply end up
leaving the language.

The powers that be didn't develop the STL. It was in widespread use
well before it was integrated into the C++ standard library.

If the demand was there, there would be at least one C equivalent, but
there isn't.

 

[Keith Thompson]

Now you've introduced a requirement for automatic garbage collection.
It's the approach I used in MiniBasic, but then it was never sold as a
fast, low-level language.

If you're going to introduce an operator that does string
concatenation, you already have a requirement for some kind of
automatic storage management (either automatic garbage collection or
automatic destructors for the temporary string objects). And you
probably need an actual string type, something that C doesn't have.

 

[lawrence.jones]

The rate at which C99 conformance is being attained by GCC could be
explained by a combination of low customer demand (C90 being adequate
for most C programmers) and relative lack of interest by implementors.

Also incompatibilities with exiting extensions. If there had been more
involvement in the C99 process by the GCC implementors (or even users),
some of those incompatibilites might have been avoided, but other were
necessary to support environments that GCC hadn't considered when
designing the extensions.

-Larry Jones

If I get a bad grade, it'll be YOUR fault for not doing the work for me!
-- Calvin

 

[lawrence.jones]

I think the came is true for ALL C compiler makes not just GCC

There's also the issue of allocation of resources. In the vast majority
of cases, the C implementors are also C++ implementors and they've been
fully engaged tracking the C++ standard rather than the C standard.

-Larry Jones

Start tying the sheets together. We'll go out the window. -- Calvin

 

[Chris Hills]

The demand was, and still is, there; however, since the powers-that-be
aren't evolving C to meet those demands, developers simply end up
leaving the language.

Developers are using C95

 

[Stan Milam]

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?

This is what libraries are for. If you are like me you have built up a
"toolbox" of useful routines over the years. I have parsers, stacks,
queues, and dynamic lists in my toolbox, so this would not present me
much of a problem.

Regards,
Stan Milam.

 

[Chris Thomasson]

[...]

Okay... We can have the 'clc_slist_push/init' functions return 'void*' in
order to do away with the casting; here is the "fresher/newer" proposed
API:

[...]

I think I will post the proposal/example code/api under the following
subject:


'The CLC Standard: LIFO Collection API Proposal'

Okay. Here is the initial code:


http://appcore.home.comcast.net/misc/clc_stack_c.html


I wanted to run this by all of you before I stick this thing in its own
thread...


Well, how crappy is it?

;^)

 

[Stan Milam]

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?

Okay, it's more than 5 lines, but a good library (the "toolbox" in my
case) can do all the heavy lifting which all the STL and BOOST is.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "toolbox.h"

int main( void )
{
int x_sub;
char wrkbuf[BUFSIZ];
LIST_T list = { NULL, 10 };
char sentence[] = "This program will reverse these words";

while (gettoken( wrkbuf, sentence, " " ) )
add_list_item( &list, dupstr( wrkbuf ) );

for ( x_sub = list.item_count - 1; x_sub > -1; x_sub-- )
printf("%s ", get_item( &list, ( char *), x_sub ) );

puts("");
return EXIT_SUCCESS;
}

Regards,
Stan Milam.

 

[Ed Jensen]

The powers that be didn't develop the STL. It was in widespread use
well before it was integrated into the C++ standard library.

When I said "...the powers-that-be aren't evolving C to meet those
demands...", I didn't mean *just* the standard C library. A lot of
things are cumbersome enough in C that it tends to preclude the
development of things like general purpose collection APIs and other
goodies.

If the demand was there, there would be at least one C equivalent, but
there isn't.

The equivalent you're talking about exists in the form of the wheel
being reinvented over and over in many projects. For example, at
every company for which I've done contract C programming, they had
their own linked list API.

What a waste.

It would be nice if the standard C library had a linked list API, even
if usage would be cumbersome due to the limitations of C syntax. The
same goes for other basics such as hash tables and real strings. It's
not like it would add any serious kind of bloat, since smart linkers
wouldn't need to link anything that isn't used.

In any case, the demand was there, and still is there. Developers are
merely solving the problem by moving to other languages, since the
evolution of C has stalled in ways important to your average
developer. Companies like Microsoft can smell the decay and aren't
even bothering to support C99.

Reading this thread has made me realize one important thing, though:
Jacob's quest for an improved C is hopeless. If the reactions I've
seen in this thread are at all representative of C developers in
general, the evolution of C will be blocked and debated and stalled as
much as possible. C is effectively frozen in time, which is fine if
you think it's already the perfect language for your project, I guess,
but I think most developers want more these days.

Jacob should forget trying to encourage a better C and just move to a
different language which suits his desires. The evolution of C has
halted, in any meaningful way, that is.

 

[¬a\\/b]

In data Sat, 06 Oct 2007 13:10:44 -0700, Keith Thompson scrisse:

If you're going to introduce an operator that does string
concatenation, you already have a requirement for some kind of
automatic storage management (either automatic garbage collection or
automatic destructors for the temporary string objects). And you
probably need an actual string type, something that C doesn't have.

sstring globalvalue;

so where is the problem if a+b return the partial (and at end the
total) result in "globalvalue"?

is the problem if "globalvalue" no resized to 0 memory very ofthen?

 

[¬a\\/b]

In data Sat, 06 Oct 2007 13:37:28 +0200, André Gillibert scrisse:

Many languages follow the three steps:
Design by one creator (it may "look" good, but be either unusable or too
platform dependent... Sometimes, it's right from the start), cahotic
evolution by implementors, and final standardization.

yes, it is not something that goes from hight