Why do you like C more than other programming languages?

[Walter Roberson]

But just out of interest, what does printf() do on a machine without a file
system or text display?

It used to be fairly common to have "single board computers" that
communicated with the outside world via RS232 serial communications.

And whatever the answer to that is, why can't it do
the same for my hypothetical graphics functions?

When I said that somewhere I had a text terminal that could
theoretically do graphics by reprogramming the fonts, I wasn't speaking
for hyperbole (though to be honest, I might have had to throw that one
away because of a Mus musculus problem a couple of years ago.) Few
people can keep up reading a sustained 960 cps text stream, but 960 cps
for graphics purposes is not much at all -- a qualitative difference
compared to the physical interfaces needed for printf() to work
successfully at the human scale

 

[Nick Keighley]

Nick Keighley said:

On 15 Jul, 13:22, Richard<[email protected]> wrote:

I wonder how often [RCH's] code gets "ported"? i.e compiled on other
systems?

I believe in the past Richard has stated that his stuff has
to run on many machines.

That is frequently the case, and in some cases I don't actually know all
the implementations in question - I ship C source, not decrees from on
high about which system thou shalt use.

Sometimes, however, I get to relax, because I know exactly which platform
the code will run on. But this is the wrong newsgroup for such a
discussion. Your interlocutor has yet to learn this. This lack is not
through ignorance (because the subject has come up many times), so it must
be through either malice or stupidity. Either way, I think you're wasting
your time replying to him, but hey, it's your time, not mine.

well on surface he appeared to be asking a sensible question.
He appeared to be wondering if your code (and by extension anyone's)
really needed C90 levels of portability. It sure make *my* life
easier.

And "my" code really does get compiled on different systems.
Usually Unix of [various flavours] and Windows. But sometimes
host and embedded.

Right. And never forget the mainframe world, where a vast amount of C is
consumed daily.

I was merely listing my own experience rather than the full universe
of C programming. I've never programmed a mainframe (does that make
me lucky? )

 

[Wolfgang Riedel]

This was true for a long time but I think it is no longer the case.
GNU C had a form of VLA that pre-dated C99, and for some time the C99
semantics were rejected. I can't find any evidence that this is still
the case. Recent C99 status reports say the differences are in some
details of when sizes are evaluated and when memory is freed. I can't
find a conformance issue with VLAs, but I trust the GCC team more than
my own investigations so I am sure there are still problems.

GCC seems to want conforming VLAs and C99 conformance in general.
Reading the various conformance statement shows this quite clearly.

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

variable-length arrays Broken
complex (and imaginary) support in <complex.h> Broken
EC 60559 (also known as
IEC 559 or IEEE arithmetic) support Broken

and some Missing and Library Issues not (yet?) done

Wolfgang

 

[Ben Bacarisse]

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

variable-length arrays Broken
complex (and imaginary) support in <complex.h> Broken
EC 60559 (also known as
IEC 559 or IEEE arithmetic) support Broken

and some Missing and Library Issues not (yet?) done

Yes. I am not sure what your point is. Mine is that this list is
much shorter the it was for previous versions so there is movement in
the right direction. Also, whilst "broken" is binary, the way it is
broken matters. Recent gcc VLA semantics are broken only in very
subtle ways.

 

[lawrence.jones]

They have been arguing against standard C since years, and

No, they haven't been arguing against standard C. They've been arguing
against using C99 for programs that are intended to be widely portable
for the simple reason that C99 implementations aren't common enough yet.
That isn't the standard's fault, and they've never said it is. They've
never said the standard is bad and should be withdrawn. They've never
said anything bad about the standard itself, just the (lack) of
implementations of it.

For what it's worth, I was on the committee, I was even the document
editor, I voted for the standard, I *like* the standard. But I don't
use C99 in my day-to-day work, either, for precisely the same reason.

(at the same time) will endlessly polemic against my compiler
for lack of standards conformance, like you.

You've admitted that there are things you haven't implemented yet.
Until you do, your compiler is not a C99 compiler. Likewise for GCC.
Bugs are one thing, but known missing features are completely different.
You seem to think that some of the standard's requirements are important
and others are not -- that isn't true. *Every* requirements is
important. Any implementation that doesn't at least *try* to satisfy
all of the requirements simply isn't a valid implementation.

Intel doesn't count. IBM doesn't count. The C99 implementation of
C99 in gcc doesn't count. The C99 implementation in lcc-win doesn't
count. HP doesn't count. Comeau C doesn't count.

How many of those implementations actually claim conformance to the C99
standard? You admit that there are things you haven't implemented yet
in lcc-win, so it doesn't count. Last time I looked, Intel, HP, and
Comeau all claimed some C99 features, but not full C99 compliance. So
you're right, most of those don't count. It looks like only IBM has an
actual C99 implementation (as opposed to an implementation with some C99
features).

 

[Walter Roberson]

How many of those implementations actually claim conformance to the C99
standard? You admit that there are things you haven't implemented yet
in lcc-win, so it doesn't count. Last time I looked, Intel, HP, and
Comeau all claimed some C99 features, but not full C99 compliance.

http://www.comeaucomputing.com/ claims,

Dinkumware has ported their standard libraries specifically for
use with Comeau C/C++ on Windows (with VC++, bcc, and mingw
backends), LINUX/Intel and Solaris/SPARC.

This combination of Comeau and Dinkumware is as close as you can
get to full compliance with Standard C++ from 2003 or 1998,
Standard C from 1999 (aka C99) and Standard C from 1990 (aka
C90).

http://www.comeaucomputing.com/#toOrder

A longer list of 4.3.3's features is available. In addition to
the new Standard C++ features that 4.3.3 supports, it also
supports the "C99" features provided in the new revision to ISO
Standard C made by the C committee in October 1999, including
so-called variable length arrays, compound literals, designated
initializers, and variadic macros. These C99 features are
supported in "C99 mode" of Comeau C/C++.

 

[jacob navia]

No, they haven't been arguing against standard C. They've been arguing
against using C99 for programs that are intended to be widely portable
for the simple reason that C99 implementations aren't common enough yet.

No. They say at each message that "tgmath isn't needed" or
"complex numbers aren't needed" or "I do not need VLAs", etc.

Each one of the messages I posted explaining some C99 feature would be
answered by one of the members of this clique with "C99 is not portable"

The few small features missing in gcc's implementation lead to
"gcc doesn't implement C99" and other statement of the same
kind.

But what bothers me the most is that precisely those people that
never did a dammed thing or write single line of code for C99
tell me that my work is nothing worth because it is missing some
small features.

I did not vote for C99 like you. I just have worked the last
ten years in a C99 implementation. Each day I have been working in
this or that, testing this or that, implementing this or that.

lcc-win has been downloaded 1 million times (we passed that benchmark
last week). Surely there are people with multiple downloads but
lcc-win has done a lot for making C99 available to many people.

And this was financed by Friedrich and me, from our own pockets!

For what?

For a bunch of do nothing that tell me that I am shrewd salesman
making money selling my software!

Total sales of lcc-win are around 100 US$ / month. That doesn't even
pay the servers that we have set up.

All this hate posts in this group directed at C99 and lcc-win are
there for you to rview if you do not believe me.

That isn't the standard's fault, and they've never said it is. They've
never said the standard is bad and should be withdrawn.

WHAT ????

You can't read?

They've never
said anything bad about the standard itself, just the (lack) of
implementations of it.

This is not true, and the answer of heathfield in this same thread
says otherwise: he doesn't like tgmath.h (genericity is something
that is to be avoided in C, that is just for C++)

In other posts he argues against VLA's etc.

You've admitted that there are things you haven't implemented yet.
Until you do, your compiler is not a C99 compiler.

Yes, obviously if I do not have 2 or 3 small features everything
is just a pile of shit. Then you will say (as the other members of
this clique) that my compiler "doesn't conform to any standard"
etc.

Likewise for GCC.
Bugs are one thing, but known missing features are completely different.
You seem to think that some of the standard's requirements are important
and others are not -- that isn't true. *Every* requirements is
important. Any implementation that doesn't at least *try* to satisfy
all of the requirements simply isn't a valid implementation.

The only things that are missing in my implementation are
designated initializers. Other stuff is implemented. The rewriting
of the C library is done (printf, remquo, floating point exceptions,
complex numbers, what have you)

But that is obviously NOTHING.

How many of those implementations actually claim conformance to the C99
standard? You admit that there are things you haven't implemented yet
in lcc-win, so it doesn't count.

Yes sure. And gcc is not a C++ compiler and MSVC isn't a C++ compiler
either. And most C++ compilers in the world have unimplemented features.

Last time I looked, Intel, HP, and
Comeau all claimed some C99 features, but not full C99 compliance. So
you're right, most of those don't count.

You haven't looked. Comeau claims conformance.

 

[Ian Collins]

(e-mail address removed) wrote:

But what bothers me the most is that precisely those people that
never did a dammed thing or write single line of code for C99
tell me that my work is nothing worth because it is missing some
small features.

Ignore them. I for one have never criticised your compiler and I never
will (until I write my own!) Your efforts with lcc-win should be
commended, not bashed.

Yes sure. And gcc is not a C++ compiler and MSVC isn't a C++ compiler
either. And most C++ compilers in the world have unimplemented features.

All but one fail to implement at least one key feature (export keyword)
but no one complains (too loudly). That's probably because they all
omit the same feature, so portability isn't compromised.

You haven't looked. Comeau claims conformance.

As does Sun cc.

 

[lawrence.jones]

I was merely listing my own experience rather than the full universe
of C programming. I've never programmed a mainframe (does that make
me lucky? )

It depends on your perspective. Pretty much everything works
differently in the IBM mainframe environment: The character set is
EBCDIC rather than ASCII, so the common printable characters all have
the high bit set and thus char is unsigned. Files have complex internal
structures, they are not simple streams of bytes. There is no
hierarchical directory structure. Floating point uses base 16 rather
than base 2 and doesn't have infinities, NaNs, or subnormal numbers.
Integers and floating-point values are stored big endian (the most
significant byte has the lowest address) rather than little endian. The
differences tend to break any code that wasn't very carefully written.

So, you're lucky in that you've never had to track down and fix all
those problems, but you're unlucky in that you've never had to track
down and fix all those problems and thus never received the extremely
valuable object lesson in the importance of coding carefully for
portability that comes with it.

 

[lawrence.jones]

http://www.comeaucomputing.com/ claims,

This combination of Comeau and Dinkumware is as close as you can
get to full compliance with Standard C++ from 2003 or 1998,
Standard C from 1999 (aka C99) and Standard C from 1990 (aka
C90).

"As close as you can get" sounds like weasel words to me, not a claim to
full conformance. If they mean to claim conformance, I wish they'd do
so in unequivocal terms.

 

[lawrence.jones]

No. They say at each message that "tgmath isn't needed" or
"complex numbers aren't needed" or "I do not need VLAs", etc.

Saying "I don't need this" is a personal value judgement and, perhaps,
an implicit criticism of the standard, but I haven't heard anyone say
"This is a terrible feature! It should never have been included in the
standard. No one should ever implement it and no one should ever use
it." You seem to interpret any criticism of C99, no matter how mild, as
equivalent to "The C99 standard is terrible! No one should ever
implement it and no one in their right mind would ever use it!"

The few small features missing in gcc's implementation lead to
"gcc doesn't implement C99" and other statement of the same
kind.

One man's trash is another man's treasure. What's a "small missing
feature" to you could be a major show-stopper to someone else. You're
welcome to make value judgements about what's important to your customer
base for your compiler, but please don't expect everyone else to agree
with those value judgements.

But what bothers me the most is that precisely those people that
never did a dammed thing or write single line of code for C99
tell me that my work is nothing worth because it is missing some
small features.

That's what you hear, but that's not what they say. All we're saying is
that you don't have a C99 compiler yet. That doesn't mean that what you
have is worthless; most people use C-like compilers every day that
aren't C90 or C99 compilers and find them to be quite valuable. The
fact that they can be persuaded to *be* C90 or, more rarely, C99
compilers makes them more valuable (at least to many of us) than
compilers that can't. Your compiler is apparently valuable to many of
your users. Some of us think it will be more valuable when you finish
your C99 implementation. Some of us think it would be even more
valuable if you would enhance it to be able to be a C90 implementation,
too. Whether you actually do either of those things is entirely up to
you.

All this hate posts in this group directed at C99 and lcc-win are
there for you to rview if you do not believe me.

I've read all of them. They're not hate mail, they're valid bug reports
and constructive criticism. You seem to be the only one who thinks they
are personal attacks on you and your compiler.

Yes, obviously if I do not have 2 or 3 small features everything
is just a pile of shit. Then you will say (as the other members of
this clique) that my compiler "doesn't conform to any standard"
etc.

Again, you're not reading what I wrote. I didn't say your compiler is
"a pile of shit", I said it wasn't a C99 compiler. Neither are most
other compilers. That doesn't make them worthless; indeed, most of them
(lcc-win included) are quite valuable. But as I said above, compilers
that can be convinced to be C90 and/or C99 compilers are more valuable
than those that can't, for many (but certainly not all) uses.

The only things that are missing in my implementation are
designated initializers. Other stuff is implemented. The rewriting
of the C library is done (printf, remquo, floating point exceptions,
complex numbers, what have

But that is obviously NOTHING.

On the contrary, it's very good! I'm glad you've made such progress;
you're further along than many other implementors.

Yes sure. And gcc is not a C++ compiler and MSVC isn't a C++ compiler
either. And most C++ compilers in the world have unimplemented features.

They're not C++ 2003 compilers. Most of them are, or can be, (so far as
I know) C++ 1998 compilers, so they can legitimately be called C++
compilers (albeit old, one might even say obsolete, ones).

 

[Serve Lau]

And even if they all conformed (which they don't), you're talking about a
tiny handful of conforming C99 implementations. You'd need ten times as
many before you could begin to defend a claim that C99 programs are
portable. And until you have Microsoft on board, such a claim is in any
case ludicrous.

When MS implements the C99 features that are accepted in the next C++
standard C99 will get a big boost. I wonder what they will do with complex
numbers and other stuff that wont make it into C++ though

 

[santosh]

When MS implements the C99 features that are accepted in the next C++
standard C99 will get a big boost. I wonder what they will do with
complex numbers and other stuff that wont make it into C++ though

Then let's get C++ to accept all (well nearly all) of C99.
Then Microsoft will have to implement them and perhaps they may be far
more reluctant to ignore WG21 and it's users than WG14 and theirs.

 

[user923005]

When MS implements the C99 features that are accepted in the next C++
standard C99 will get a big boost. I wonder what they will do with complex
numbers and other stuff that wont make it into C++ though

Why does C++ need the C complex package? They have <complex> already.
I would much rather use complex numbers naturally than use function
calls to operate on them.

 

[jacob navia]

Why does C++ need the C complex package? They have <complex> already.
I would much rather use complex numbers naturally than use function
calls to operate on them.

lcc-win offers exactly that.

That is why operator overloading is a good idea.

 

[Richard]

lcc-win offers exactly that.

That is why operator overloading is a good idea.

Operator overloading has caused more code bases to become unreadable
quagmires than any thing I can think of.

 

[jacob navia]

Operator overloading has caused more code bases to become unreadable
quagmires than any thing I can think of.

If you have for instance

bigfloat a,b,c;

a=b+c;

That is less readable than

assign(&a,add(b,c));

???

 

[Richard]

If you have for instance

bigfloat a,b,c;

a=b+c;

That is less readable than

assign(&a,add(b,c));

???

Now remove the bigloat decl and put it a few pages away. And then
extrapolate a little.

 

[jacob navia]

Now remove the bigloat decl and put it a few pages away. And then
extrapolate a little.

Yes, and still
a=b+c;
seems clearer to me than
assign(&a,add(b,c));

specially for

a = (sqrt((b+c)/(b-c)))/2;

I will not even ATTEMPT to translate that!

 

[Kaz Kylheku]

If you have for instance

bigfloat a,b,c;

a=b+c;

Clearly, this instance of overloading follows the expectation that = implements
assignment, and that + adds numbers.

It's as clear for bigfloat as it is for double or int.

That is less readable than

assign(&a,add(b,c));

But assign and add are not standard library functions; they are user-defined.
So you aren't necessarily overloading anything here.

You're only arguing for the supremacy of infix syntax for expressing
arithmetic.

Prorammers create confusion when they redefine that standard infix syntax in
counter-intuitive ways for things other than arithmetic.

So a better anagy would be to compare these two:

widget a, b, c; // widgets are not like numbers at all

a = b + c; // = is not really assignment, and + doesn't add

to this:

widget a, b, c; // widgets are not like strings, either

strcpy(a, strcat(b, c));

If overloading of these standard functions was allowed, it could also be abused
like this.

This, I believe, is the strongest version of the point being made by opponents
of operator overloading: redefining the standard language core with strange
meanings.

This argument is wrong, because the overloading can be done responsibly.
Anything can be abused. That's why we are able to have obfuscated coding
contests.

When we remove useful features because they can be abused, we are treating
intelligent, responsible grownups as mental retards or children. Most such
grownups will rebel against condescension that stands in the way of doing
useful, obvious things that improve their productivity.