C needs a BOOST

[jacob navia]

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.

 

[Chris McDonald]

At the tail

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

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

 

[Keith Thompson]

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?

 

[jacob navia]

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]

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

 

[Chris McDonald]

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

 

[Keith Thompson]

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.

 

[Eric Sosman]

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

"I do not accuse" is present tense, and it's true: after
several people castigated you and after a few attempts to deny
that you'd done such a thing, you amended your proposal to
remove the offending language. But the moving finger writes,
and the memory lingers.

Wrong again.

So, Google not only has a bad Usenet interface, but they
(or someone) are actively making forged posts under your name?
Go to google.groups.com, navigate to comp.lang.c, search for
__declspec, sort by date, and there you have it:

>>> [...] It is interesting that this
>>> document mentions almost all the __declspec constructs but
>>> doesn't mention one I considered important and use very often:
>>>
>>> __declspec(naked)

The supposed date of this post is September 21, within living
memory. Is it a defamatory forgery? Will you take legal action?
Google Groups also displays a September 6 post in which someone
claiming to be you describes removing the "neglected" language;
is that, too, a forgery? Are the black helicopters hovering?

A young cousin of mine once forgot, as children will, some
simple instruction he'd been given. His exasperated parent
berated him for his terrible memory. "But," said the lad, "I
have a very good forgettory!" A convenient ability, I guess.

 

[Eric Sosman]

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.

 

[Ian Collins]

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.

 

[Richard Heathfield]

André Gillibert said:

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]

jacob navia said:

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.

 

[Chris Thomasson]

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

 

[Chris Thomasson]

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

IMHVO, C is to low-level to standardize trivial collection interfaces.
However, I bet we could standardize an API for this newsgroup.

 

[Ian Collins]

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

You can also code it cleanly without resorting to macros!

 

[Richard Heathfield]

Chris Thomasson said:

IMHVO, C is to low-level to standardize trivial collection interfaces.
However, I bet we could standardize an API for this newsgroup.

Previous attempts by clc to participate in similar projects have not been
conspiciously successful.

Still - hope springs eternal, eh?

 

[John Whorfin]

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

http://www.research.att.com/~gsf/download/ref/cdt/cdt.html

 

[David Resnick]

[...]

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.

Um, what about:

int list_add(List *list, ...);

With the type of the variable argument known based on something set in
the
List when it is created? Mind you, that might be painful to use, but
it
seems to work. I guess all pointer lists would be void* or some such.

-David

 

[Neil Booth]

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

Jacob, you do your argument no favours with falsehoods like this.
It just shows you don't know what you're talking about.

 

[jacob navia]

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

Jacob, you do your argument no favours with falsehoods like this.
It just shows you don't know what you're talking about.

Of course "I do not know what I am talking about".

You do. Please tell us then, some proposition that gcc has done
since C99 for standardization. Or proposal. Or whatever in this
direction.

If possible I would like to know if the C99 support
is finished in gcc. Even if it is very good, the last thing I
know is a web page where VLAs and other features are marked missing
or broken.

http://gcc.gnu.org/c99status.html

Since I am not a member of GNU I have just to believe the
public information that GNU itself publishes. Sorry.