Has thought been given given to a cleaned up C? Possibly called C+.

[bartc]

I don't know the spec of signal(), but an array of pointers to a function
taking two ints and returning a pointer to a double, might be:

I found this:

void ( * signal(int, void (*)(int)))(int)

which with the help of cdecl (which was itself a job and a half to track
down a working copy) told me this:

"declare signal as function (int, pointer to function (int) returning void)
returning pointer to function (int) returning void"

In the suggested syntax it can be written as:

function (int, *function(int)void ) *function(int)void

The name "signal" can either go after the first "function" (to be in line
with how ordinary functions are defined) or at the end (the same as how
variables might be defined); either way, it's at one end or the other, not
buried in the middle:

function signal(int, *function(int)void ) *function(int)void {...}
function (int, *function(int)void ) *function(int)void signal;

If that's still too cryptic then * can also be optionally written as
"pointer to", and "returning" can be optionally added after the ")", so that
it looks like:

function (int, pointer to function(int) returning void ) returning pointer
to function(int) returning void

It is now identical to the main part of the cdecl output.

 

[bartc]

bartc wrote:

And the typedef statement itself, which instead of having the
type-spec on one side, and the alias for it on the other, is all
mixed up: typedef int tenvector[10];

the typedef name is in the middle of the type-spec!

That's actually irrelevant - the typedef is remarkably easy to use. To
define a synonym for an existing type, all you have to do is pretend
you're defining an object of that type, and stick typedef on the
front.

This is a method I /have/ to use in order to write typedefs, because I do
not find them intuitive.

As well as decomposing complex type-specs into a hierarchy of typedefs.

These are just ways around the difficulties of the type system.

Let's say you want a synonym for an array of ten pointers to
function taking const char * and returning int.

You're assuming I know what const char * means (and so did I). Cdecl tells
me it's actually a pointer to const char (not const pointer to char).

....

typedef int func(const char *);

func is now a type synonym. We use this in the next stage: ....
typedef func arr[10];

arr is now a synonym for "array of ten pointers to function taking
const char * and returning int".

It's hard to see how this could be made much simpler.

To summarise, to declare a variable x with such a type:

typedef int func(const char *);
typedef func arr[10];
arr x;

Which is an alternative to writing (with some help from cdecl):

int (*x[10])(const char *);

The typedefs at least turn it from impossible to possible, although in my
scheme, it would just be:

[10]*function(* const char)int x;

It doesn't *look* that different, but I managed to write it in a few seconds
from your description above, and anyone can understand it by reading from
left to right.

(And applied also to the typedefs, they might look like this, if they are
still written like variable declarations:

typedef function(* const char)int func;
typedef [10]func arr;

The name being defined is now always on the right.)

 

[Ian Collins]

No, the first ISO C++ standard was published in 1998.

Oops, must be getting old and getting my decades muddled up!

Even so, the STL was in widespread used before C++ was standardised.

 

[jacob navia]

Thomas Richter a écrit :

Thus, "I'm running out of arguments", right? (-;

No. It is just that it loops:

jacob: We can improve C by adding A and B

thomas: No, C can't be improved. It is a bad language because
it lacks A and B. Use C++ instead.

jacob: But it is precisely my argument that we should A and B
to the language.

thomas: C is low level and nothing should be improved. It is low level
because it lacks A and B. Use C++ that has A and B.


etc.

 

[Dag-Erling Smørgrav]

Because the C standards committee has always decided NOT to add such
an improvement to the language. The C++ standard committee decided that
such an improvement WAS NECESSARY, and they develop one.

No they didn't. They adopted and standardized an existing interface.

DES

 

[Dag-Erling Smørgrav]

Why don't you take path which boost library used for C++? It wasn't
standard, but people started to use it and it's now de facto standard.

It's also (mostly) crap.

DES

 

[Dag-Erling Smørgrav]

quite correct. This harping on about keywords is just silly. You can
write code that compiles with both and a C compiler and a C++
compiler. And it isn't that hard.

From scratch, yes. Most existing C code will need modifications, such
as casts for malloc() and renaming variables or functions called new and
delete (which are the most common conflicts). The implicit "struct" /
"class" will get you in trouble if you're in the habit of typedefing
structs. You will also have to wrap headers for external C libraries in
extern "C" { } if they aren't already. Older code may contain K&R-style
function declarations and definitions (!prototypes), which won't work.

DES

 

[Malcolm McLean]

You still don't get it, don't you? I'm not a "C++ advocate". I'm a "use
the right tool for the job" advocate. That might be C, C++, java,
pyhton, bash, or whatever else is out in the field.

That sounds so sensible that no-one would ever disagree with it.

The problem comes when the costs to using the tools are significant.
Imagine a carpenter who has to walk from village to village picking up
odd jobs. He'll take a hammer and a saw. A lathe and a drill would
also be handy, but take too much and he's got to hire an assistant to
carry the toolbag, which means that he'll have to bump up his charges
considerably. Using a nail where ideally you'd put a screw might be
the best solution.

Similarly the costs of having some code in C, some in C++, some in
Java, some in Python are very considerable.

 

[ImpalerCore]

One interesting question is why, after over 30 years of use, there
hasn't appeared a widely accepted a general and extensible container
interface for C?

The C++ STL appeared fairly early on in that language's evolution and
was rapidly and widely accepted by C++ developers.  The widespread use
resulted in it being incorporated into the standard library in first
language standard.

Why hasn't the same thing happened with C?

That is a very good question. I think that you may have hinted at the
problem already, "C++ STL appeared fairly early on".

I imagine that the Stepanov and other people pursuing generic
containers didn't think C could provide the right support. The fact
that C++ standardization was fluid while he was working on his ideas
certainly made for easier acceptance by that language. C++ at that
time had much less inertia compared to C, and better language support
for his ideas. The longer a feature (the two big ones are a standard
container library, and concurrency) is not available in the
development of a language's toolset, the more likely that the
implementation of that feature will be fragmented across the
architectures and the people who need it. I believe the fact that the
STL came together in C++'s infancy led to more general acceptance as a
whole. Delay the STL enough, maybe a couple of years, and I believe
that C++ would have had the same problem, maybe.

I may be completely off, but those are my current thoughts on the
question.

Best regards,
John D.

 

[ImpalerCore]

Ian Collins a écrit :





Because the C standards committee has always decided NOT to add such
an improvement to the language. The C++ standard committee decided that
such an improvement WAS NECESSARY, and they develop one.

I have written most of the STL clone (AVL trees, RB trees, bitstrings,
flexible arrays, lists (double/single linked) and the whole library
is extremely fast and compact. It is just less than 100K when you use
all of it. If you use just the lists module it is less than 5K.

But apparently all this work is a waste of time. The committee decided
a feature freeze already, and I will not be ready to present this to
the next meeting in April.

And C has been waiting for a standard generic container library for
what, like 30 years? I don't think there's any hurry on this, and I
don't know if the committee is even looking for a container library.
I believe that the C++ committee reached out to Stepanov, or it's
likely that his work wouldn't have come to fruition in C++ the way it
did. I would think that a container library having 'de-facto'
standardization similar to boost would be a prerequisite to even think
about C standardization. Why should they invest a lot of time and
energy debating the rules and semantics when the result may not be
accepted by the compiler or C community at large? Having a de-facto
library that has garnered support from the C community would give your
argument a bit more weight.

I don't know if it's even possible to get a de-facto container
standard these days. Many people have their own pet library that they
use and it may be difficult if not impossible to motivate them away
from it. I believe that your pursuit of a generic standardized
container library in C would be an endurance race, not a sprint.

I don't believe the work is ever a waste of time. Even if the C
standard committee rejects your proposal doesn't invalidate the
attempt. If you make standard committee acceptance or rejection your
definition of whether the effort is worth it, then I believe you are
doing it for the wrong reasons. If you are doing it because you love
doing it, then the work *is* worth it no matter the outcome. In the
end, you have to realize that the only person who you have control of
is yourself.

Best regards,
John D.

 

[Jasen Betts]

One interesting question is why, after over 30 years of use, there
hasn't appeared a widely accepted a general and extensible container
interface for C?

The C++ STL appeared fairly early on in that language's evolution and
was rapidly and widely accepted by C++ developers. The widespread use
resulted in it being incorporated into the standard library in first
language standard.

Why hasn't the same thing happened with C?

too much work for too little gain.

C does not have templates, only macros, and using macros template
functiuons longer than 5 lines are hard to maintain, and longer than
50 are impossible.



--- news://freenews.netfront.net/ - complaints: (e-mail address removed) ---

 

[Flash Gordon]

Lorenzo Villari a écrit :

Doesn't it have some kind of graphics library as part of the standard?
Or did someone mis-lead me many years ago?

For an example of a full C only program using advanced GUI features
see the lcc-win debugger.

The debugger+IDE+Project management+Editor+grep+diff+reformater+etc
is just 800K (windows 32 bit).

Only C allows you the speed AND power of direct GUI access with access
to the low level debugging API.

No, if the API is available to C it is also available to C++.

Also, when writing a GUI I don't normally want to get under the hood by
accessing the GUI directly, I normally want to use a nice powerful
widget set that does a lot of the hard work for me.

 

[Seebs]

No. It is just that it loops:

I think you are not following his argument.

jacob: We can improve C by adding A and B

thomas: No, C can't be improved. It is a bad language because
it lacks A and B. Use C++ instead.

He absolutely said nothing of the sort.

He did not say C was "a bad language". He did not say "C can't be improved".

He did say that he didn't think that adding A and B to C would improve it,
but rather, that it would make more sense to use languages which have
them.

You know what's an awesome feature in a programming language? An "eval"
operation, which interprets strings as code. Incredibly flexible and
powerful.

Do you think we should add eval() to C? I don't.

thomas: C is low level and nothing should be improved. It is low level
because it lacks A and B. Use C++ that has A and B.

I do not think this is a fair representation of his argument.

Here is a piece of advice I got from a friend once: If you want to argue
with someone, a good starting point is to understand their position well
enough that you can present their argument well enough that *they* agree
that you are presenting their argument fairly and well. If you can do that,
then it's reasonable to move on to arguing with them. If every time you
claim you are presenting their argument, they say "no, that's not what I
said at all", then you aren't ready to argue against them, because you don't
understand what they said.

I believe his argument is that he does not feel that adding A and B would
improve C. For instance, I don't think that adding operator overloading would
improve C. I think it would make C worse. One of the things I like about
C is the confidence that I know what it's doing. Operator overloading is
a great fit for an OO language, where I expect objects to have internal state
and define their own rules. It's a poor fit for a language where I
expect operations to map very closely onto machine instructions.

-s

 

[Seebs]

And C has been waiting for a standard generic container library for
what, like 30 years? I don't think there's any hurry on this, and I
don't know if the committee is even looking for a container library.

I'm not on the committee these days, but I really don't think a container
library is the right class of problem for the language spec to solve.
There are simply too many design tradeoffs that, *for C programs*, are too
significant for the language to nail them down.

The problem is, if we provide a "container library" in the spec, people
will be strongly inclined to use it even when it's a bad fit. I'm not sure
I want to do that -- look at the damage done by rand()!

I have seen a few possible container designs for C. None of them have
particularly appealed to me. Of the ones I've seen, the one that... uhm...
Guy whose name I've forgotten. The "embedded containers" approach, where
you have a list pointer anywhere in an object, and convert a pointer to the
list member of the object back into a pointer to the object. That's by far
the nicest -- and I'd never seen it until a couple-few months ago. Which
is to say, if we'd standardized any of the things I'd heard of by 2005 in
the language, we'd have missed a really good idea.

I don't know if it's even possible to get a de-facto container
standard these days. Many people have their own pet library that they
use and it may be difficult if not impossible to motivate them away
from it. I believe that your pursuit of a generic standardized
container library in C would be an endurance race, not a sprint.

I would agree. And I think it's important to realize that there are going
to be mutually-exclusive requirements, so either you implement more than one,
or you write it off as being impossible.

I don't believe the work is ever a waste of time. Even if the C
standard committee rejects your proposal doesn't invalidate the
attempt. If you make standard committee acceptance or rejection your
definition of whether the effort is worth it, then I believe you are
doing it for the wrong reasons. If you are doing it because you love
doing it, then the work *is* worth it no matter the outcome. In the
end, you have to realize that the only person who you have control of
is yourself.

Totally agreed. I don't expect the language to pick up my string library
or my list library, but I use them and like having them around.

-s

 

[Walter Banks]

One interesting question is why, after over 30 years of use, there
hasn't appeared a widely accepted a general and extensible container
interface for C?

Feature additions in C essentially takes two things.

1) A working example of new feature that is part of a current set of tools.
This is important to understand the implementation ramifications
and resolve the implementation conflicts that transforms a good
idea into good practice.

2) A champion that will formally explain and promote the new feature.
New ideas are debated on several levels. Does the new
feature address a real need, does the need have a broad application.
Are there alternative approaches. What is the impact on the existing
code base.

To answer the question some of the same people serve on C and C++
committees and one of the differences they saw between the languages
was it was more appropriate for an extensible container to be promoted
for C++ and not in C. I don't remember an extensible container
interface for C ever being discussed in WG-14.


Regards,

Walter..

 

[jacob navia]

Jasen Betts a écrit :

too much work for too little gain.

C does not have templates, only macros, and using macros template
functiuons longer than 5 lines are hard to maintain, and longer than
50 are impossible.

A container library doesn't need macros. You can use void * and
it works.

I have developed a container library using plain C, and I have
already:
o lists (single/double linked)
o flexible arrays
o bitstrings
o AVL trees
o Red/Black trees

and it is not finished yet.

 

[Ian Collins]

That is a very good question. I think that you may have hinted at the
problem already, "C++ STL appeared fairly early on".

I imagine that the Stepanov and other people pursuing generic
containers didn't think C could provide the right support. The fact
that C++ standardization was fluid while he was working on his ideas
certainly made for easier acceptance by that language. C++ at that
time had much less inertia compared to C, and better language support
for his ideas. The longer a feature (the two big ones are a standard
container library, and concurrency) is not available in the
development of a language's toolset, the more likely that the
implementation of that feature will be fragmented across the
architectures and the people who need it. I believe the fact that the
STL came together in C++'s infancy led to more general acceptance as a
whole. Delay the STL enough, maybe a couple of years, and I believe
that C++ would have had the same problem, maybe.

I may be completely off, but those are my current thoughts on the
question.

I think you probably are on the right track (at least you have the same
thoughts as me!). Early adoption was the key. I guess the same applied
to the C standard library; most of it was in use on early Unix systems
and the standard simply standardised existing practice (see a lot of the
examples in the original K&R).

Along with early availability, there has to be a strong desire from
users to improve and grow a language. Drawing another comparison with
C++, compare the work going on with C++0x and C99. By the time C++0x is
ratified, there will probably be more (almost complete) implementations
of it than there are C99, over a decade after ratification. A large
part of the new standard library is already in widespread use. There
are also significant improvements to the core language, driven by a
desire to improve upon what we currently have. One of these is language
support for concurrency, so if the will is there, it's never too late!

<OT>
For anyone interested, http://www2.research.att.com/~bs/C++0xFAQ.html
gives an incite into motivations for the new C++ standard.
</OT>

 

[Ian Collins]

That sounds so sensible that no-one would ever disagree with it.

The problem comes when the costs to using the tools are significant.
Imagine a carpenter who has to walk from village to village picking up
odd jobs. He'll take a hammer and a saw. A lathe and a drill would
also be handy, but take too much and he's got to hire an assistant to
carry the toolbag, which means that he'll have to bump up his charges
considerably. Using a nail where ideally you'd put a screw might be
the best solution.

Or he will buy a van and grow is business because ha can tackle a
broader range of jobs. He will do the job in less than half the time,
to the client pays less.

I like that analogy!

 

[Ian Collins]

From scratch, yes. Most existing C code will need modifications, such
as casts for malloc() and renaming variables or functions called new and
delete (which are the most common conflicts). The implicit "struct" /
"class" will get you in trouble if you're in the habit of typedefing
structs.
Why?

You will also have to wrap headers for external C libraries in
extern "C" { } if they aren't already. Older code may contain K&R-style
function declarations and definitions (!prototypes), which won't work.

A good excuse to fix them!

 

[jacob navia]

Flash Gordon a écrit :

No, if the API is available to C it is also available to C++.

No. As you (may) know, you have to write
extern "C"
in C++

Also, when writing a GUI I don't normally want to get under the hood by
accessing the GUI directly, I normally want to use a nice powerful
widget set that does a lot of the hard work for me.

That's a viewpoint. Another viewpoint (mine) is that experience has told me NOT to use any widget
set but use the API. This way, I have been able to run programs written under windows 16 bits
today under windows 64 bits.