Why do you like C more than other programming languages?

[CBFalconer]

.... snip ...

Always the same discussion. First somebody claims something is
not portable because it doesnt work on some arcane system. Then
somebody else brings in something from the current standard that
doesnt work on that same system either. And then the talk about
hosted/freestanding starts.

So we have an easy fix then. Just add to the standard:

*networking support is not required under freestanding
implementations*

However the matter is even simpler. If you read the existing
standard, you will discover that *networking support is not
required" under ANY implementation.

 

[santosh]

santosh said:


...and right again.


I don't understand why you make an exception for lcc-win - its
maintainer's attitude towards the Standard seems to be an idyllic
combination of ignorance and contempt.

Well jacob has often expressed his desire to see various functions and
extensions added to C1x. Presumably he would be delighted if WG14 were
to add interfaces for directories, networking etc. Whether he would be
able to make his implementation conform to the Standard is a separate
matter of course.

 

[santosh]

Fine. When you are writing for DVD player, you can pretend C has no
network and other functions. What difference will that make to your
code?

The point is that the vast majority of implementors already provide
extensions for doing these things (or if not, the platform provides
it's own routines), and some of them even have existing standards.
There is no point in duplicating them in C.

Let's assume that implementation foo on platform bar provides the baz
library to do networking. Do you think that they will readily drop
their well implemented, known library and implement what the C standard
happens to specify for doing the same thing?

Now C++ is in the process of standardising a threading model, but the
situation is different with C++. It has more momentum and vendor
support on the kinds of platforms and domains were things like network
and threading are heavily used. It also has a more visible (and perhaps
more numerous) user base than C.

How come? If an implementation X does not have support for networking,
why(perhaps how is more appropriate) will you use the networking
library on that system?

The value of a portable language lies in the fact that you can use it's
features with a great degree of assurance that it will be supported and
available wherever a conforming implementation exists. As soon as you
start adding features that only a few platforms can support and
different features supported on different platforms, portable
programming would become no easier, IMO, than using a non-standard
library for these tasks in the first place.

There is a great difference; but portable libraries do exist.

Exactly. So what would be gained by merely changing the interfaces and
including them in C1x? Perhaps it would become "standard" on paper, but
hardly much would change in practise. At least that's what I believe.

[ ... ]

You generally do not write a TCP/IP protocol stack or a raster
graphics library, do you? So, more often than not, it is the built-in
routines that we use.

Indeed, but the discussion is about whether it would be appropriate to
include these features into *C* . I believe one of C's strengths has
been it's minimality and consequent simplicity. We already have C++ for
those who want a "bells and whistles" C, and Java, Perl, Python and
others for those who want everthing including the kitchen sink in one
language.

If C tries attempts to go their way, I suspect that it would quickly
fail. IMO, YMMV.

 

[James Dow Allen]

Then you are probably prejudiced.
Each language has certain merits and demerits.

Personal preferences may be an important factor.
Just as some learn best visually and others orally,
so different people will find different language
features to be irritating or hard-to-learn.
The bickering between C and C++ users, for example,
might calm down if each side understood the choice
was partly a matter of personal taste.

(Nevermind that you may need language X to get job Y.
If it's all about money why don't you just seek
a career in law, finance, politics or some other
criminal activity?)

In my own case, I used to program in assembly languages
when none of the obvious reasons were present, simply
because I enjoyed it more than Fortran, which was then
the obvious alternative. The ambiguity about DO-loop
variables irritated me, and assembler had much better
expressive power for pointers, at least compared with
Fortran's then-dialect.

As another example I found "call by value/reference"
to be confusing and was delighted to discover C, where
you get the distinction for free without any keyword
or English-language discussion: inserting the normal C
operators '*' and '&' appropriately allows an effective
call-by-reference transparently. For me the sparse
set of primitives in C made it easier to learn than a
"richer" language, but others may find the converse to
hold.

I'm not sure what this implies about the "best first
language to learn." One might argue that one should
learn an irritating language first -- that way you're sure
to be motivated to learn at least a second language!
(On the other hand, with all the distractions available
to a virile young man I'd guess programming first in
an *enjoyable* language would be your best bet.)

James Hussein Allen

 

[bill]

There are many languages around: C++, JAVA, PASCAL, and so on.  I
tried to learn C++ and JAVA, but ended up criticizing them.  Is it
because C was my first programming language?

I like C because, comparatively, it is small, efficient, and able to
handle large and complex tasks.

I could not understand why people are using and talking about other
programming languages.

It really depends on what you're doing. I've used C, which is the
best language IMO for hard-core CPU intensive algorithms, since
well... forever. It's lacking high-productivity capabilities like the
Standard Template Library (STL) in C++, but I get around that with
DataDraw database generator (datadraw.sf.net). The nice thing about C
is I can ignore even it's fairly light set of features, and still be
highly productive. We don't use C structures, pointers, or arrays,
since DataDraw allows my programs in C to run much faster using
integer indexes into arrays of properties.

People seem to like garbage-collection in Java and other languages. I
think that's a load of crap. To destroy an object, you still have to
unlink it from every relationship manually, and if you miss one,
you've still got a memory leak. All you get with garbage collection
is that you don't have to write the "free" or "delete" line. Gee that
saved me what... .1% of my code? Using DataDraw in C autogenerates
destructors for me, which allows me do the whole job in one line, a
savings much more worthwhile.

What really kills me is that every major language out there has
stupidly (IMO) adopted the serious limitations inherent in C
structures. On 64-bit machines, we're wasting 64 bits per object
reference, when I know of no applications that have more than 4
billion objects of a given class. By forcing memory organization in
structures in memory, we trash the L2 cache because we load a whole
structure into cache each time we just need one field. In a recent
benchmark of large graph traversal, using C structures slowed the
program down 7X relative to the DataDraw version, while the STL
version was 15X slower, all due to crappy L2 cache performance.

There's a lot of enthusiasm for new languages. I like much of the
code I've seen written in Java, which IMO is due to the hand-rails the
language offers programmers in terms of coding in a particular style.
Once you know the style, you can do it in any language, and gain most
of the benefits. For example, Java allows only single-inheritance.
That's a *great* idea. They force pointers to be used as object
references, another great idea. Write once, run anywhere - another
great idea, even if it's only partly true.

 

[Linonut]

* (e-mail address removed) peremptorily fired off this memo:

So the Win32 and Win64 APIs will certainly survive in the short/medium
term. But 15 or 20 years from now? Who knows.

So what? You (the end-user programmer) don't /need/ the Win32 API, not
even to do Windows programs.

Use a portable API.

 

[Linonut]

* Ian Collins peremptorily fired off this memo:

Boy I'm gad I only use POSIX systems!

Indeed. Best to stick with portable APIs.

Even if the one-time leader of the Microsoft Visual Studio team did say

"Portability is for canoes."

 

[Ian Collins]

What really kills me is that every major language out there has
stupidly (IMO) adopted the serious limitations inherent in C
structures. On 64-bit machines, we're wasting 64 bits per object
reference, when I know of no applications that have more than 4
billion objects of a given class. By forcing memory organization in
structures in memory, we trash the L2 cache because we load a whole
structure into cache each time we just need one field.

Only if you build for 64 bit. One reason for doing that is to access
more than 2^32 bytes of memory. Like all things C, you don't pay for
things you don't use.

 

[Kaz Kylheku]

Always the same discussion. First somebody claims something is not portable
because it doesnt work on some arcane system. Then somebody else brings in
something from the current standard that doesnt work on that same system
either. And then the talk about hosted/freestanding starts.

So we have an easy fix then. Just add to the standard:

*networking support is not required under freestanding implementations*

This discussion is largely bullshit, because it basically revolves about how
various engineering standards should be physically decomposed into documents;
in other words, which way is the paper cut.

Fact is that on some given system, I can use the C compiler to write networking
code. That code is even portable to other systems that have the same
networking interface. I couldn't care less if it's in the language or not;
I have the entire API of the system at my disposal, and that makes up the
C-based dialect in which I can program that system.

To write my code, I make use of features described in ISO C, and library
features described some other documents.

When we say that networking should be in C, we are really saying that the
document which defines the language should be extended with additional chapters
about networking (perhaps identical to those which I already have in my system
documentation, or another ISO or IEEE standard).

But there is no point in doing this, because that stuff is already in another
document.

It's up to the system users and their vendors to negotiate what programming
interfaces they want in the system and its toolchain. They can do that without
having all of those interfaces crammed under the umbrella of a programming
language.

Sometimes there are competing implementations of some interface in the market.
Which interface should ``win'' and get to be in the language? Whose
multithreading interface should be in the language? Which graphical interface
library? Et cetera.

C and POSIX have common roots, yet are separate. The standard C library started
out on Unix, together with C. The POSIX and C standardization committees were
created at about the same time, and divided library features between
themselves. They had to decide things like that the stat function would go into
POSIX, wheras malloc would go into C. Then they went their separate ways.

One good reason was done is that C was already used on non-Unix systems, which
didn't have the entry points corresponding to the Unix library functions.
Implementing the POSIX library would involve operating system emulation.
Those chapters in the standard would have to be optional. A chapter of optional
features in a standard is precisely as good as a separate standard!

Another good reason is simply that if you have too much stuff in a programming
language (i.e. one single document) it becomes more cumbersome to maintain that
document. When it comes time to ratify the document, then all of the
subdocuments contained within it have to be ratified. A delay in ratifying any
of the subdocuments delays the entire document. The meetings about the
document will be larger because they will involve more people. Larger meetings
will be slower and less productive. This means that it will take longer to get
anything done. Maybe the working group will have to be broken into smaller
working groups, which will work only with their section of the document. But
this is precisely as good as having separate documents with separate ISO
numbers, and their own release schedule!

Even the distinction between a hosted and freestanding C implementation could
be captured by fragmenting C into two documents: a base document describing the
freestanding features, and an additional separate document describing the
library, declaration of main, different implementation limits etc.

 

[s0suk3]

jacob navia said:



Good for you - but the fact remains that your compiler conforms to neither
C90 nor C99, you frequently rail against the requirements of the Standard,
and you ask questions that indicate your knowledge of it to contain
significant gaps.



You exaggerate your case. I have certainly criticised C99, partly for
introducing features that seem unnecessary, and partly because so few
conforming implementations exist after all this time. When it becomes as
widely implemented as C90, it will become useful. Wake me up when that
happens, won't you?


Where portability matters, C99 is not an option. Even where portability
doesn't matter, C99 is frequently not an option. So how could I possibly
recommend it? It would be unkind to suggest to people that they introduce
non-portability into their code by using C99 features.




I don't think you know what the word means. It is precisely because so many
implementors cannot be bothered to implement C99 properly that it is
impractical to recommend it for people to use. Of course, some
implementors can't even be bothered to implement C90 properly...

Nonsense. You've just expressed a bunch of apparently personal
opinions without giving any arguments to them. Why is C99 not
portable? Why do the features that it introduces seem unnecessary to
you? (I find most of them incredibly useful.) Why is it "not an
option" when portability matters, and even when portability doesn't
matter?

By the way, the fact that there are too few C99 implementations is not
the Standard's fault.

 

[Nick Keighley]

this looks like an argument to me... (see later)

Where portability matters, C99 is not an option. Even where portability
doesn't matter, C99 is frequently not an option. So how could I possibly
recommend it? It would be unkind to suggest to people that they introduce
non-portability into their code by using C99 features.

[...] It is precisely because so many
implementors cannot be bothered to implement C99 properly that it is
impractical to recommend it for people to use. Of course, some
implementors can't even be bothered to implement C90 properly...

Nonsense. You've just expressed a bunch of apparently personal
opinions without giving any arguments to them.

he's not alone in them.

Why is C99 not portable?

lack of compilers. See also C#

Why do the features that it introduces seem unnecessary to
you?

only Richard can answer this. But they don't tempt me much either.
If C99 compilers were readily available (and implemented at least
a consistent subset of the standard) I'd be more interested.
bool, int*_t, VLAs, snprintf, designated initialisers,
variadic macros all look interesting. complex I've no interst in.

(I find most of them incredibly useful.)

good for you

Why is it "not an option" when portability matters,
compilers

and even when portability doesn't matter?
pass

By the way, the fact that there are too few C99 implementations is not
the Standard's fault.

no, but in the real world compiler availability matters.
Why is C# an unusual choice of language in embedded
programming?

 

[jacob navia]

this looks like an argument to me... (see later)

Where portability matters, C99 is not an option. Even where portability
doesn't matter, C99 is frequently not an option. So how could I possibly
recommend it? It would be unkind to suggest to people that they introduce
non-portability into their code by using C99 features.

[...] It is precisely because so many
implementors cannot be bothered to implement C99 properly that it is
impractical to recommend it for people to use. Of course, some
implementors can't even be bothered to implement C90 properly...

Nonsense. You've just expressed a bunch of apparently personal
opinions without giving any arguments to them.

he's not alone in them.

Yes, he has a lot of followers in the pedants group here.
They have been arguing against standard C since years, and
(at the same time) will endlessly polemic against my compiler
for lack of standards conformance, like you.

lack of compilers. See also C#

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.

The only thing that counts is that gcc/lcc are missing a few features.

only Richard can answer this. But they don't tempt me much either.

GREAT! You have won some points here. Maybe you will be appointed
dear Richard's best pupil!

If C99 compilers were readily available (and implemented at least
a consistent subset of the standard) I'd be more interested.
bool, int*_t, VLAs, snprintf, designated initialisers,
variadic macros all look interesting. complex I've no interst in.

Those are your personal choices. They should be standardized in
"C according to Nick"

good for you

and bad for you

compilers

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.

pass

Yes pass. Better keep quiet here.

 

[Richard]

(e-mail address removed) said:


(In other words, there are too few conforming C99 implementations for its
portable use to be practical.)

LOL.

Again the real world and Heathfield's agenda to keep c.l.c as his own
private stomping ground come to blows!

 

[santosh]

LOL.

Again the real world and Heathfield's agenda to keep c.l.c as his own
private stomping ground come to blows!

Well, all he is saying is that C99 is not sufficiently widely
implemented for his standards of portability. He isn't preventing
anyone from writing C99 code if their portability requirements are met
by existing compilers, or if they wish to do so in spite of it. I can't
see what you are laughing at.

 

[Bartc]

Your functions would not be implementable on machines that do not have
displays or do not have bitmapped displays.

Mine wasn't a serious proposal. I realise that the C language is now a
closed book and will not be taken further, at least not in interesting ways.

But just out of interest, what does printf() do on a machine without a file
system or text display? And whatever the answer to that is, why can't it do
the same for my hypothetical graphics functions?

 

[s0suk3]

(e-mail address removed) said:


(In other words, there are too few conforming C99 implementations for its
portable use to be practical.)



Sorry, I thought I'd given the arguments. But hey, never mind my personal
opinions - let's listen to someone else's opinion on the matter.


"there are too few C99 implementations" - (e-mail address removed)


Because portability matters to me, I have to do without those features,
because - as (e-mail address removed) rightly says - "there are too few C99
implementations".


Great! I am very, very pleased that you find them useful. What's more,
they're even topical here, so we can discuss them to our hearts' content.
Nevertheless, I don't know how useful they are because I don't use them
because I can't guarantee that my users will be able to compile code that
uses them because, as the wise man rightly said: "there are too few C99
implementations".


Because, in the words of one (e-mail address removed) - "there are too few C99
implementations".

LOL! Sorry; I guess those two last lines of my previous post were a
bit misleading. When I said "the fact that there are two few C99
implementations...", I was echoing your words from the post I replied
to, not making an affirmation of my own. So those lines would have
read more accurately:

"By the way, the fact that there are too few C99 implementations (*if*
that's true, as you claim) is not the Standard's fault."

Anyway, yes, that's a point. But, as Jacob Navia puts it:

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

The only thing that counts is that gcc/lcc are missing a few
features."

So, the fact that "there are too few C99 implementations" might not be
true fact, as some people argue.

The overall problem is one of fragmentation. There are "too few C99
implementations", but there are plenty of C99-- implementations out there,
where people have taken C90 or C95 and bolted onto it the bits of C99 that
they like the look of, not always adhering to the Standard's requirements
either (cf gcc's VLAs, which are "broken" but which are unlikely ever to
get "fixed" because the gcc folks like them just the way they are).

So C99 has become a fragmented language - someone uses a C99 feature on
system A, but then finds that it doesn't work on system B because it
doesn't compile, whereas it compiles just fine on system C but doesn't
work the same as on system A. Nightmare.

Now, that's a problem when portability matters. When portability doesn't
matter, you have a different, but related, problem - Person A asks a
question, and Person B gives a purist C99 answer, but Person A doesn't
have a conforming C99 compiler, and it so happens that the feature Person
B recommends isn't implemented on Person A's system (or, worse, is
implemented in a way that works just fine according to its own lights, but
not in accordance with the requirements of the Standard). So you get this
fragmentation within the newsgroup too - effectively, the questions become
questions not about the language but about the implementation. So, unless
an OP really is using a conforming C99 implementation (which is very
unlikely), the only effective recommendations are: Use C90 or C95; buy a
real C99 implementation (which, let's face it, is a waste of words for the
vast majority of people asking here); or go ask on an implementation
newsgroup.

Shouldn't Person A adapt to his/her needs the code that Person B
kindly tried to help with, instead of Person B having to adapt the
code to help Person A whose preferences might not be known at the time
of the response?

That's somewhat like saying that in a general programming newsgroup
people should post C code instead of Lisp code, because C is more,
say, popular, than Lisp. Of course, that doesn't apply to comp.lang.c,
because we're discussing standard C here. What's not stated is what
version of the standard we're discussing.

That is, it becomes *impractical* to recommend C99 on comp.lang.c, and this
is because "there are too few C99 implementations", as the man rightly
said.


No, it isn't the Standard's fault. The Standard is just a document.

Of course. In this context, the term "The Standard" refers to everyone
and everything involved in the development of the Standard.

The fault lies partly with the people who drafted the document and who so
completely misjudged their user community, and partly with implementors
for not implementing the Standard. It is also the case that users have
been very remiss in their historic duty of kicking down their
implementors' drawbridges, waving pitchforks and demanding C99 conformance
- but why should they?

If you want C99 to become practical, grab a pitchfork and head down to your
implementor.

This far it's been practical enough for me.

But look around you. If you're going to storm a castle, you really ought to
take an entire mob with you.

Nobody[1] *cares*. C90 works fine for everyone, and for many their attitude
is "if my compiler supports it, it's C, and I don't need port ability
because I haven't got a boat".

And that is why "there are too few C99 implementations". Nobody[1] is
interested.

[1] Okay... ALMOST nobody...

How can you make such a generalizing claim? I doubt very much you have
talked to enough people in the globe to formulate statistics for that
statement. Have you?

 

[vippstar]

Bartc said:



Implementations for such a system are likely to be freestanding
implementations, which are not required to provide support for printf (and
many other library functions).

It's also possible that file streams are implemented as a resizable
array of unsigned char, or that printf() always fails.

<snip>

 

[Ben Bacarisse]

The overall problem is one of fragmentation. There are "too few C99
implementations", but there are plenty of C99-- implementations out there,
where people have taken C90 or C95 and bolted onto it the bits of C99 that
they like the look of, not always adhering to the Standard's requirements
either (cf gcc's VLAs, which are "broken" but which are unlikely ever to
get "fixed" because the gcc folks like them just the way they are).

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.

 

[Richard]

Well, all he is saying is that C99 is not sufficiently widely
implemented for his standards of portability. He isn't preventing

I wonder how often his code gets "ported"? i.e compiled on other
systems? Other systems where the set of C99 additions discussed really
are not available.

anyone from writing C99 code if their portability requirements are met
by existing compilers, or if they wish to do so in spite of it. I can't
see what you are laughing at.

He isn't "preventing"? Wow! That's mighty of him. All Hail the
Heathfield for that bit of kindness.

 

[Nick Keighley]

I wonder how often his 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.

And "my" code really does get compiled on different systems.
Usually Unix of vatious flovours and Windows. But sometimes
host and embedded.

Other systems where the set of C99 additions discussed really
are not available.

I honestly don't know. but the trouble is it involves some
crystal ball gazing. I don't know which software is going to
be ported and I don't know where it's going to be ported to.

C99 doesn't seem to offer me much. And threatens a portability
hazard. Even reasonably well written C doesn't port smoothly.

<snip>