Specifications for operator overloading

[Keith Thompson]

Richard Heathfield wrote: [...]
]
They are not the only ones; Mr Navia's timing is as exquisite as
ever. In comp.programming today, over five hours before Mr Navia's
claim that lcc-win32 is the only C compiler being developed now, a
new C compiler ("bgb", I think it's called) was released, with
full source code. It lacks one or two features as yet (the author
cites "static" and struct initialisation), but then he's only been
working on it since late March, so that's understandable.

I haven't had the opportunity to play with it yet, but a (very)
quick perusal of some of the source code suggests that the author
seems to know what he's doing.

[...]
This is the a strange thing indeed. It is curious that someone
that insists in gcc -pedantic doesn't get bothered that a C
compiler accepts "string" and "list" as a keyword. But anyway
maybe I am wrong because the source code is a mix of another
project (a lisp nterpreter code?) and some C compiler stuff and
some other languages that I am not sure I can really
classify.

I see nothing strange about it. Richard explicitly said that (a) it's
not a fully conforming C compiler, and (b) he hadn't looked closely at
it.

Anyway, thanks for the URL, and I am sure Mr Heathfield will tell
us more about this great compiler soon.

He's under no obligation to do so. His point was merely to refute
your claim that "Lcc-win32 is the only *C* compiler being developed
now". Do you continue to stand by that claim?

 

[Jack Klein]

Yes. C is frozen forever. But that doesn't matter since we have
C++.

Languages such as C++, Java, C#, scripting languages, and many others,
have tended to narrow the range of applications programmed in C. It
seems unlikely to me that any large scale development organization
would start a brand new application with 100K or more LOC in C today.

So be it, there are two application areas where C still reigns.

The first is the one it was originally designed for, system
programming. You will get flamed in C++ groups if you suggest that
one couldn't completely rewrite UNIX or even Windows completely in
C++, but in the real world C is the language in which operating
systems are written.

The second is one that Brian Kernighan probably never gave much
thought to, embedded systems. Not too surprising, when you put it in
historical perspective. The earliest versions of C preceded the Intel
8080, the first true microprocessor, by several years.

The single largest category of processors in existence are those in
cell phones, mostly ARM derivatives of one sort or another. The
execute code written in C, and applications written in Java. The
earlier versions used a software JVM written in C. Newer ARM versions
actually have a hardware partial JVM, so only part of the Java is
executed by an interpreter written in C.

All new developments are done in C++, and there is no way out.

This is so absurd, the real problem is that you don't have the
faintest idea of 90% or more of the development in C. Despite your
constant complaints of the narrow vision of the C community, or at
least of the regulars in comp.lang.c, you completely fail to realize
that most of the C development happening today has nothing at all to
do with desktop computers.

If you reworded your statement above as, "All new desktop application
developments are done in C++", it would still be wrong. Do some
research, I think you will find that in total the use of Java, C#,
managed C++, Ruby on Rails, and a few others greatly out weigh the use
of C++.

On the other hand, if you said, "Almost no new desktop developments
are done in C", I would say you are absolutely correct.

The vast majority of C development these days is not in desktops or
servers, not even in hosted environments at all, and note that an OS
kernel is generally not itself a hosted environment, although it
provides a hosted environment to applications running on it.

In fact, a large percentage of C development these days is done on
non-conforming implementations that only implement part of the
language. Most implementations for 8-bit targets do not provide
floating point types at all, or only a single precision type. Most
16-bit implementations, and even some 32-bit implementations, don't
support a floating point type that meets the minimum requirements for
a double.

You are carrying on here about extending C, making it a bigger and
more powerful language, and complaining that posters here are not very
sympathetic to your aims.

But you're not even talking to the audience that is paying real money
for new C compilers today.

Go ask on groups like comp.arch.embedded, comp.sys.arm, and comp.dsp,
and see if the C programmers in that group would place a high value on
extending C with operator and function overloading.

Each time somebody tries to improve C, the proponents of
"The better C" will keep things as they are.

There are advantages to keeping the language small, simple, and
efficient. There are many other languages, many of them more complex
and more feature rich. Why do you think C needs to emulate their
features? Why not pick a language for a task that has the best match
of features?

The committee has stated the same view that you say:

C is dead. No new developments, corrections, whatever
until 2019. Then, C will be well forgotten.

Can you provide a link to a statement to this effect from any member
of the committee?

I am trying precisely to do the opposite.

No, you are trying to add features to C. Whether or not your
particular choice of features are improvements is a matter of your
opinion.

I think C is a language that needs small changes but is
basically sound. Lcc-win32 is the only *C* compiler being
developed now. All others are C++ compilers that happen
to compile C. That is why C99 failed: the compiler writers
do not see any C market since all C programmers should be
doing C++.

Indeed, there are many small changes that could be made to improve C,
not just a few. The question is whether or not the particular
extensions that you propose are among those "small changes". At a
philosophical level, there are differences between "improvements" and
"extensions".

As for your statement "Lcc-win32 is the only *C* compiler being
developed now", see http://www.christian-heffner.de/ The most recent
release of Pelles C was April 4, 2007.

C99 has been ignored by gcc and Microsoft because both organizations
promote C++, that, as everybody should know by now, is THE
BETTER C!

This is quite poor logic on you part, and some gross inaccuracies.

Microsoft is most specifically not promoting C++ these days, they are
promoting C# and preferring, if C++ must be used at all, that one use
their "Managed C++", an abomination that they rammed into an ISO
standard through a back door, the same one they are trying to use now
to define their own proprietary "open standard" document format.

The logical fall icy is the unfounded leap to from the fact that the C
community is suspicious of one person's ideas of additions to the
language to the conclusion that the C community, or anyone else other
than the C++ community, maintains that C++ is a better C.

Personally, I like the fact that you provide your compiler for free
download and use, and I have installed and used various versions over
time. And it is an excellent way to try out proposed
changes/extensions/additions to the language, for later proposal for
inclusion to the standard. Proposals with actual working
implementations stand a much better chance of serious consideration.

But it is not gracious, at the very least, to launch tirades at those
who don't share your vision for the direction that future extensions
should move C.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[CBFalconer]

jacob navia wrote, On 03/09/07 19:36:
.... snip ...


You know better than that. The gcc developers have definitely *not*
ignored C99 and nor have the glibc developers. They have not *finished*
implementing it, but then you had not finished last time you talked
about the status of your compiler either. A few others have actually
finished implementing C99.

Now will you stop claiming people have said things they have not said?
There are places where your discussions about extensions would be
topical as you well know having been pointed there several times.

Actually I just took a look at
<http://http://gcc.gnu.org/gcc-4.2/c99status.html> and am
pleasantly surprised at the extent to which gcc has adapted. The
hard thing, at some point, will be replacing all the system
libraries. What is missing will not affect the majority of
programs IMO.

 

[Karl Heinze]

His point was merely to refute your claim that "Lcc-win32 is the only *C*
compiler being developed now". Do you continue to stand by that claim?

See:
http://www.smorgasbordet.com/pellesc/


K. H.

 

[Karl Heinze]

Yes. C is frozen forever.

Well, at least it's present state (and it's near future) looks rather
bad... :-(

Incredible: In 2007 gcc still is not fully C99 conforming! :-(

All new developments are done in C++ [...]

Right, C++0x is already underway...

Each time somebody tries to improve C, the proponents of
"The better C"
You mean C++?

will keep things as they are.

The committee has stated the same view that you say:

C is dead. No new developments, corrections, whatever
until 2019.

Is this really true? :-(

But, on the other hand, maybe those people are right? Maybe C++ IS the
better C? (I mean, nobody can FORCE you to use the object oriented
stuff in C++, right?)

I am trying precisely to do the opposite.
Right.


I think C is a language that needs small changes ...

Clearly /references/ (especially in connection with function calls)
would be a good thing in C.

Lcc-win32 is the only *C* compiler being developed now.
All others are C++ compilers that happen to compile C.

Ehem... And what's with Pelles-C?! (Though it's also a LCC descendant
it's certainly in no way related to lcc-win32.)

See:
http://www.smorgasbordet.com/pellesc/

That is why C99 failed: the compiler writers do not see any C
market since all C programmers should be doing C++.

I guess, you are right.


K. H.

 

[Laurent Deniau]

Yes. C is frozen forever. But that doesn't matter since we have
C++.

C and C++ are very different and do not target the same things except
maybe efficiency.

All new developments are done in C++, and there is no way out.

After 12 years of C++, I have decided to go back to C. This might be
uncommon, but I had (and still have) very good reasons to do so.

Each time somebody tries to improve C, the proponents of
"The better C" will keep things as they are.

I see the "C Object System" as an extension (in the sens of CLOS for
Common Lisp) which lifts C to the level of other recent OO languages
(at least). It offers an incredible flexibility (with reasonable
efficiency) that I haven't found in any other language (amongst about
10 languages). The fact that it's only a library shows that C has
already great possibilities by itself. BTW a new (much cleaner C89,
aka 0.8) version will come soon ;-)

The committee has stated the same view that you say:

C is dead. No new developments, corrections, whatever
until 2019. Then, C will be well forgotten.

I am trying precisely to do the opposite.

I read your proposal, but most of what you propose is more related to
library extension than language extension. I think that C programmers
are trained to rewrite their own lib instead of using broken
implementation (see "C interfaces and implementations"). I observed
that experienced programmer are more sensitive to language features
(orthogonal, clean, non-ambiguous, simple, ...) than libraries, Java
being a good example of the impact of this point of view.

I think C is a language that needs small changes but is
basically sound.

I agree. But once these small changes (this list needs a concensus!)
are done, I would prefer something stable and widely available than
"yet another incomplete/broken implementation". Simplification of the
standard would probably help to get stable implementation.

Lcc-win32 is the only *C* compiler being
developed now.

comp.lang.misc just annouced a new C compiler...

All others are C++ compilers that happen
to compile C. That is why C99 failed: the compiler writers
do not see any C market since all C programmers should be
doing C++.

Still, most portable libraries are written in C and most languages
have a FFI for C, not C++.

C99 has been ignored by gcc and Microsoft because both organizations
promote C++, that, as everybody should know by now, is THE
BETTER C!

gcc team made many proposals for language extension and some of them
are rather nice. I have recently seen the proposal for _Alias which I
find more elegant than overloading by name mangling (more in the
philosophy of C) and I suggested the author to extend it to operators.
That would be nice!

a+, ld.

 

[Army1987]

If C90 led to C99, no reason C99 can't lead to C2010. Nothing requires it
to be frozen.

I think that C90 was much more widely implemented in 1999 than C99
will be in 2010. Though "frozen forever" is way too pessimistic
IMO.

"Happen to"? No. Even in cases where they are combined, they are
*designed* to compile C, they don't simply do so by happy accident. At
least, this is true of the Gnu compiler.

Indeed. A compiler where
#include <stdio.h>
int main(void)
{
printf("%d\n", (int)sizeof 'A');
#ifndef __cplusplus
puts("Ha Ha!");
#endif
return 0;
}
displays a number greater than one, a newline, "Ha Ha!", and
another newline is not a C++ compiler. At least, it is not *just*
a C++ compiler. It may well be *also* a C++ compiler, but that is
no more relevant that the fact that gcc (GNU Compiler Collection)
is also a Fortran compiler.

 

[Kelsey Bjarnason]

[snips]

Kelsey Bjarnason said:


They are not the only ones;

Oh, I didn't mean to imply they were; they were simply a quick and easy
disproof of his claim.

Mr Navia's timing is as exquisite as ever.
In comp.programming today, over five hours before Mr Navia's claim that
lcc-win32 is the only C compiler being developed now, a new C compiler
("bgb", I think it's called) was released, with full source code.

Yeah, well, lcc-win32 or bust, right? Anything to sell another copy.

 

[Flash Gordon]

CBFalconer wrote, On 04/09/07 02:02:

Actually I just took a look at
<http://http://gcc.gnu.org/gcc-4.2/c99status.html> and am

That should have been http://gcc.gnu.org/gcc-4.2/c99status.html

pleasantly surprised at the extent to which gcc has adapted. The
hard thing, at some point, will be replacing all the system
libraries. What is missing will not affect the majority of
programs IMO.

If you look at http://gcc.gnu.org/c99status.html you will find they are
still *slowly* making progress. It would be nice if they progressed
faster, but at least there is sign of progress.

 

[jacob navia]

We had a very good discussion about this recently. Some people asked for
a full documentation. I have upload it to this URL:

http://www.q-software-solutions.de/~jacob/proposal.pdf

jacob

I have posted parts of that document to comp.std.c