Talk:C (programming language)/Archive 13

Archive 10

Archive 11

Archive 12

Archive 13

Archive 14

Archive 15

→

Archive 17

Proposed external link

"Development of the C Language" by Dennis Ritchie 1Z (talk) 18:50, 23 October 2011 (UTC)

That's already reference #3. Rwessel (talk) 19:21, 23 October 2011 (UTC)

What about this information from "The Unix-Haters Handbook"?

B Creators Admit C, Unix Were Hoax FOR IMMEDIATE RELEASE In an announcement that has stunned the computer industry, Ken Thompson, Dennis Ritchie, and Brian Kernighan admitted that the Unix operating system and C programming language created by them is an elaborate April Fools prank kept alive for more than 20 years. Speaking at the recent UnixWorld Software Development Forum, Thompson revealed the following: “In 1969, AT&T had just terminated their work with the GE/AT&T Multics project. Brian and I had just started working with an early release of Pascal from Professor Nichlaus Wirth’s ETH labs in Switzerland, and we were impressed with its elegant simplicity and power. Dennis had just finished reading Bored of the Rings, a hilarious National Lampoon parody of the great Tolkien Lord of the Rings trilogy. As a lark, we decided to do parodies of the Multics environment and Pascal. Dennis and I were responsible for the operating environment. We looked at Multics and designed the new system to be as complex and cryptic as possible to maximize casual users’ frustration levels, calling it Unix as a parody of Multics, as well as other more risque allusions. “Then Dennis and Brian worked on a truly warped version of Pascal, called “A.” When we found others were actually trying to create real programs with A, we quickly added additional cryptic features and evolved into B, BCPL, and finally C. We stopped when we got a clean compile on the following syntax: for(;P("\n"),R=;P("|"))for(e=C;e=P("_"+(*u++/ 8)%2))P("|"+(*u/4)%2); “To think that modern programmers would try to use a language that allowed such a statement was beyond our comprehension! We actually thought of selling this to the Soviets to set their computer science progress back 20 or more years. Imagine our surprise when AT&T and other U.S. corporations actually began trying to use Unix and C! It has taken them 20 years to develop enough expertise to generate even marginally useful applications using this 1960s technological parody, but we are impressed with the tenacity (if not common sense) of the general Unix and C programmer. “In any event, Brian, Dennis, and I have been working exclusively in Lisp on the Apple Macintosh for the past few years and feel really guilty about the chaos, confusion, and truly bad programming that has resulted from our silly prank so long ago.” Major Unix and C vendors and customers, including AT&T, Microsoft, Hewlett-Packard, GTE, NCR, and DEC have refused comment at this time. Borland International, a leading vendor of Pascal and C tools, including the popular Turbo Pascal, Turbo C, and Turbo C++, stated they had suspected this for a number of years and would continue to enhance their Pascal products and halt further efforts to develop C. An IBM spokesman broke into uncontrolled laughter and had to postpone a hastily convened news conference concerning the fate of the RS/6000, merely stating “Workplace OS will be available Real Soon Now.” In a cryptic statement, Professor Wirth of the ETH Institute and father of the Pascal, Modula 2, and Oberon structured languages, merely stated that P. T. Barnum was correct.

Page 338 of "The UNIX-haters handbook" http://simson.net/ref/ugh.pdf — Preceding unsigned comment added by 86.125.191.144 (talk) 11:59, 18 December 2011 (UTC)

I haven't looked at the link given, but I read UGH some years ago and can recommend it for some affectionate and interesting (and pointy) commentary. However, the joke about C is not suitable for mention in this article. Johnuniq (talk) 02:05, 19 December 2011 (UTC)

It was a joke. The end. --Macrakis (talk) 16:08, 19 December 2011 (UTC)

Edit in characteristics section by Chcampb

The following discussion was started by Chcampb on my talk page. It properly belongs here. Rwessel (talk) 04:17, 27 October 2011 (UTC)

-- Regarding a bullet edit at C (Programming language) --

I realize the point you made in the revert comment, but the change that I had made addressed several issues,

1) The fact that multiple assignments do not work on the same variable was not made clear. I propose changing the the text to "More than one variable may be assigned to in a statement. This is common in idiomatic C."

2) There are two sentences in that bullet; the first is kludgy, and the second does not reference assignment. The fact that function returns can be ignored is stating that they do not need to be assigned, but indirectly. The new bullet was to separate the two ideas (as they were written to be independent anyways).

3) Back to the original bullet, the 'idiomatic' link is not applicable except as an external link to a discussion on idiomatic statements in programming languages. The current article lacks the clarification one would expect from such a link, as it is more concerned with natural languages.

Do you agree? Disagree?... I don't want to change this back just to have you (or someone else) nuke it. — Preceding unsigned comment added by Chcampb (talk • contribs) 03:45, 27 October 2011 (UTC)

Agree partially. The function return comment deserves its own bullet. The idiomatic comment should get pulled. But I think just "multiple assignments allowed" is enough - this is not the spot to delve into what is or isn't undefined behavior according to the standard, and it's rather more complex than that anyway, involving side effects, aliased pointer dereferences, and whatnot. But I've made those changes. For the future, this sort of discussion should be on the talk page for the article, that way all the regular editors would see it (anyone who has the C (programming language) on their watch list, would also be notified of changes to the talk (discussion) page. For clarity, I'll copy this discussion to the article talk page, let's continue any discussion there. Rwessel (talk) 04:13, 27 October 2011 (UTC)

There is more to it than multiple assignments in a single statement. The fact that an assignment-expression has a value is part of a general design that allows a lot to be accomplished in a single expression. The &&, ||, ?:, and comma operators are part of that, and parentheses and macros also contribute. A general statement to this effect might be more useful than focusing too narrowly on assignment. — DAGwyn (talk) 01:05, 2 December 2011 (UTC)

I don't believe C supports multiple or parallel assignment, where e.g. you can exchange values A and B using A,B = B,A. Nor does it support destructuring assignment, where the elements of a sequence/record can be broken out using something like A,B = quotientremainder(x,y). It does allow chained assignment, but this is not a special syntactic or semantic feature of the language: "=" associates to the right, and returns the assigned value. That is, A=B=3 is equivalent to A=(B=3). --Macrakis (talk) 23:15, 21 December 2011 (UTC)

Not efficient on all hardware!

C is not an efficient language for IBM mainframes. That is to say: it was, because now machine instructions were added specifically for C programs.

Example: C extensively uses "null-terminated strings". Handling these strings requires tedious loops that move byte by byte, each time testing for a NULL byte, while mainframes typically used instructions that allow the movement of many bytes at the time - as long as the number of bytes to be moved is known in advance (varying from 256 to 16777216 bytes, 2**24).

Also, C used to be very inefficient on IBM AS/400 systems, because C programmers typically use subroutines extensively, and subroutine calls are very expensive on these machines. But perhaps that is also solved now, because nowadays all systems must properly support C. Rbakels (talk) 14:11, 1 December 2011 (UTC)

What is the point of the above? Do you propose some editorial change to the article? Actually one of the earliest C implementations was for the IBM 360 family, and it was reasonably efficient. Your complaint about null-terminated strings suggests that you think "efficient" means "giving easy access to specific hardware features;" C does allow access to block-move operations (e.g. memcpy), but chose a different representation for basic character strings for a variety of reasons (see a nearby discussion about that). Compilers can, and do, optimize generated code to take advantage of particular characteristics of the target platform. As to subroutine usage: if C encouraged a change in the hardware to better support modular programming, that is to its credit; computer scientists and software engineers generally understood the value of functional modularity at the time that C was invented, and nearly every significant programming language has provided a comparable feature. Perhaps the existing text is not clear enough — C aimed to replace assembly language in most circumstances, so it was designed to produce run-time code that was not significantly slower than assembly language in most cases, on most platforms, and it succeeded in that goal. — DAGwyn (talk) 00:55, 2 December 2011 (UTC)

Local variables and subroutine parameters are in C supposed to be stored on the stack, and there is supposed to be machine instructions to directly support this. If there aren't, then at least in assembly, all variables will be fixed in memory. If you want to write efficient code on such a system, use only global and static variables, like assembly would. Don't blame C as a bad language if it has a feature that the hardware doesn't support well, instead avoid using that feature. --BIL (talk) 05:56, 3 December 2011 (UTC)

If need be, a hardware-supported stack mechanism (which virtually all modern CPUs support) can be substituted by another method, e.g. linked segments. It shouldn't be necessary to avoid use of function invocation-local variables, which are a great boon to using recursive methods. — DAGwyn (talk) 06:24, 21 December 2011 (UTC)

There is nothing in the specification of C that says that local variables must be stored on the stack. I've seen implementations for Intel 8080 CPUs that used reserved fixed-address memory areas to simulate a stack (since accessing fixed addresses is considerably faster than calculating stack offsets on that CPU). The reason for local variables is that that is what they are - variables that have local scope to their containing function. As for efficiency on IBM mainframes, C should be about equal to PL/1 on that architecture. — Loadmaster (talk) 21:18, 21 December 2011 (UTC)

I have written compilers for the S/360 and other machines without explicit instruction set support for stacks or stack frames. Not a big deal. It may take a few instructions more than on a machine with such support, but it's not necessarily much slower (cf. RISC). The main challenge is getting efficient and clean error-checking for stack overflow.

Null-terminated as opposed to counted strings have a variety of issues on all instruction set architectures, including architectures with built-in null-string handling. Efficiency is only one of them. The article C string handling discusses some of the issues; the article Null-terminated string discusses more. Those articles could probably bear to be improved.... It might be appropriate in this article to include a tiny bit more on this, e.g. "Strings are not a separate data type, but are implemented as null-terminated arrays of characters with operations supplied by string functions in the standard library." --Macrakis (talk) 23:28, 21 December 2011 (UTC)

That sounds like a good way to state it, and some mention of strings as such should be made since object-oriented languages provide (more or less) intrinsic string objects. However, I don't immediately see a good place to mention it in the article; perhaps under the "Library" section? — Loadmaster (talk) 18:58, 11 January 2012 (UTC)

Title of an external link in the References section need to be corrected in the article

In the section titled "Criticism", there is the following line:

         For example, the conditional expression in if (a=b) is true if a is not zero after the assignment,
         which cites a reference numbered [17].

And if you click the link of reference [17], which is the following:

          http://www.cs.ucr.edu/~nxiao/cs10/errors.htm

You can notice that the title of the webpage is 10 Common Programming Mistakes in C++

and not related to C.

So we need to make the necessary changes. Thanking you. — Preceding unsigned comment added by Gansai9 (talk • contribs) 09:34, 30 January 2012 (UTC)