Talk:C (programming language)/Archive 8

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 5

Archive 6

Archive 7

→

relatively simple compiler

"Among its design goals were that it could be compiled in a straightforward manner using a relatively simple compiler,"

Is that supported by the historical documentation? (please excuse my ignorance). If so, what was it in comparison to? There seems to be pretty general agreement that regardless of the original design goals, C actually requires a comparatively complex compiler. (Or you can use a restricted C compiler. Or you can use a C compiler with wrong bits.)

Which falsifies the next bit "As a result, C code is suitable". Regardless of the historical design goals, C requires a complex compiler. Compiler simplicity is not why it is suitable for system design tasks. If simplicity of compiler was the criteria, FORTRAN or Pascal would be more suitable, which in general they are not. 218.214.148.10 02:20, 7 December 2006 (UTC)

Well, C evolved from relatively simple beginnings. The main contributor to the rapid spread of C on other than the original PDP-11 platform was undoubtedly the development of the "Portable C Compiler", which drastically reduced the amount of work needed to create a C compiler for a different target architecture. There were several stages in the evolution of the PCC, too.Of course these days everybody uses GCC for a similar purpose. — DAGwyn 23:54, 7 December 2006 (UTC)

A possible relevant comparison would be PL/1 (the original application for C was to be the implementaion language for Unix, whose predecessor Multics was written in PL/1), which by all accounts was a horribly complex language to write a compiler for. C, and especially early K&R C, is in fact rather simple to compile. A graduate student equipped with a LALR parser generator could probably implement a working compiler for K&R C from scratch in a few months. It wouldn't produce terribly good code by today's standards, mind you. (Newer versions of the language have added some complications, of course - e.g. parsing complex declarators in the presence of typedef names is not for weenies). Much of the relevant competition in the early 1970's need quite ad-hoc parsers and do not have the clean separation between core language and library that make C compilers so simple. Your suggestion that FORTRAN compilers would be simpler to write than C ones strikes me as so wrong I don't even know where to start refuting it. Henning Makholm 05:29, 10 December 2006 (UTC)

In my experience (which goes way back and includes FORTRAN and C compiler construction), constructing a compiler for FORTRAN versus C around 1975 would have required roughly the same amount of work, assuming a reasonably clean ISA. Fortran's run-time support library would have been somewhat larger, since it couldn't use early C's trick of mapping shorter data types into longer ones, and also had to support built-in I/O facilities. (For a fairer comparison, one should add at least the stdio package to the implementation.) There were contemporaneous languages that had features that required more complicated compilation, e.g. "thunks" for some procedure parameters in Algol. Even so, building a whole compiler from the ground up would still require a simialr amount of work. The actual attribute of C that I think should be mentioned instead is, C programs had a "transparency", such that one could pretty much predict the machine code that would result from a given source, especially on the PDP-11. Without built-in exponential (FORTRAN **) and array operators, there was little or no hidden execution cost in C source code; if an algorithm took yay many patent source-code operations, it took a comparable number (expanded by some small factor, on the order of 2) of machine operations. — DAGwyn 21:01, 11 December 2006 (UTC)

I second your opinion on the "transparency" of C code, that's one of the reasons why C could be compared to a portable (machine independent) assembly language. /HenkeB 16:56, 1 March 2007 (UTC)

I reject your opinion on the "transparency" of C code. I am using gcc for embedded applications, and the code emitted is both unpredictable, and less predictable than other languages I have used. Is this because I am using gcc? (It is very poor at selecting registers) In any case, it compares very poorly for predictability and line-optimisation with other languages I used c1987.—The preceding unsigned comment was added by 150.101.166.15 (talk • contribs) 05:55, 10 July 2007

There was of course no hidden execution cost for array operators: have you ever looked at the code generated?

C was not compared to a macro assembly language because of it's "transparency" by anyone who knew macro assembly languages: that's laughable. Nor was it compared to a macro assembler by the people who built and used it: they fought against that characterisation. It was compared to macro assembler by it's enemies, because of it's lack of features.

To the contrary, on its original platform (PDP-11 Unix), C programmers generally could predict just what machine code would be emitted for their C constructs, and since the compiler's code optimization was relatively limited, they often chose their C constructs specifically to ensure that certain code would be produced. For example, do..while with decrement for its condition, to make sure that a SOB looping instruction was generated. — DAGwyn 14:27, 10 July 2007 (UTC)

218.214.148.10, For some historical documentation, there are implementations of C which were based on recursive-descent parsers, such as Small-C (Ron Cain 1980) which were useful for the early microprocessors (no floating-point values), and which are still in use for embedded systems. See Dr. Dobb's Journal for Ron Cain's work. --Ancheta Wis 03:59, 14 December 2006 (UTC)

I believe that first compilers were simple. There are current compilers that support this fact. In particular, the Obfuscated Tiny C Compiler that was made for the 2002 IOCCC has a little more than 2048 bytes source code. Also, its evolution, tcc is a pretty much complete C compiler, assembler and linker has a 100 KB binary executable. --hdante 12:47, 6 January 2007 (UTC)

Tiny C was designed to be exactly that subset of C for which a simple compiler was possible. Thus, the mere fact of Tiny C might indicate that C itself is too much for a simple compiler. — DAGwyn 00:39, 14 January 2007 (UTC)

Or one could say that Tiny C was designed to be compiled in a straightforward manner using a relatively simple compiler, relative to C. :) – Smyth\^talk 16:28, 14 January 2007 (UTC)

Negativity of this article

Am I the only one taken by the overwhelming negativity of this article? All it seems to cover is its limitations rather than its strengths, and what features it lacks and criticism but barely highlights its upsides and that many of the so called criticisms are intentional design decisions. Every other sentence seems to be "C doesn't have such-and-such". Contrast this to Pascal (programming language) or Python (programming language), where there is barely any criticism. I feel having the sheer amount of negativity leaves the impression that C is a 'bad' language and as such this isn't a neutral article. -Halo 12:05, 3 January 2007 (UTC)

I wrote the negative sections of this article and C is my favourite language. This may have to do with some of the more positive sections being moved out to other articles. In any case I don't think there's a POV problem - although we could certainly do with more information on its successes. Deco 12:13, 3 January 2007 (UTC)

C attracts criticism partly because it is so successful. Its success is also mentioned in the article. A while back I moved the Criticisms section to a separate article to restore some balance. C is like a sharp knife: preferred by expert whittlers, but dangerous in unskilled hands. — DAGwyn 04:46, 4 January 2007 (UTC)

Hi, I think you are right. It would be more encyclopedic if we concentrated on what C can do and move most criticism to its own section or Criticism of the C programming language. This may improve the article quality and simplify some sections. --hdante 21:44, 4 January 2007 (UTC)

Generally I agree; for example the list of features that C lacks could be merged into the Criticism of the C programming language article, leaving in the main C article the list of features that C has. — DAGwyn 06:56, 6 January 2007 (UTC)

I would also like to remark that a lot of the criticism, particularly listing features that C lacks, seems POV and slightly misses the point of the language. Criticising C for not having built in garbage collection is like criticising Python/PHP for not having pointers - it's true, it's accurate, but kinda misses the point -Halo 09:58, 6 January 2007 (UTC)

This kind of criticism may be simplified if we say that C is often used as an application language, instead of a system language and then give examples of such criticisms (like lack of garbage collector) to show that people miss the point. However, I don't have a reference to back it up. --hdante 11:51, 6 January 2007 (UTC)

Binary operator associativity

I could swear saw some code demonstrating that certain lines' output (something like "a++ + ++a") was not defined/compiler specific because the associativity of + and * is not specified. Yet this article lists them all as L->R associativity... Is this correct? The samples I saw may have been C++ but I don't think the languages differ in this area. AllUltima 00:46, 8 March 2007 (UTC)

Operator precedence and sequence points are separate concepts. a++ + ++a is undefined because a is modified twice without an intervening sequence point. The associativity of the operators is unimportant. Pfaffben 05:56, 8 March 2007 (UTC)blp

Pfaffben is right about them being different concepts; pre- and post-increment dont really fit into the precedence table well because pre- and post-increment are different beasts depending on where the same syntax sugar is placed. The FAQ's for C and C++ both address this exact scenario of more than one increment operator without sequence points. Enjoy the read. John Vandenberg 07:00, 8 March 2007 (UTC)

C99 - Variables can be declared anywhere ???

Is it true? I believed that it is correct only in С++.

Visual Studio 2005 shows errors while compiling this code:

int main(){
	int a;
	a = 10 * 2;

	int b = a;

	return 0;
}

main.c(5) : error C2143: syntax error : missing ';' before 'type'

Maybe it is a mistake in the article? ILYAki 09:13, 22 April 2007 (UTC)

It is clear in the C99 standard that it is possible (see reference I added in the C99 paragraph). It works perfectly well in DevC++ (using GCC). The problem is with VS, which is not at par with the C99 standard (this is stated in the article, C support is not as good as for C++ in Visual Studio). So I think it is another compiler incomplete support for the latest C99 standard. Hervegirod 10:25, 22 April 2007 (UTC)

Thanks for reference, now I see it.ILYAki 05:22, 23 April 2007 (UTC)

Importance assessment

I don't know why this article is rated as "Mid" (Subject fills in more minor details). I rather think that being what C is for computer programming, it should be rated "High" (Fortran is "High", and C is as important for the history of software than Fortran, may be much, considering that C influenced many more languages, and was fundamental to Unix, and then Linux) Hervegirod 10:32, 22 April 2007 (UTC)

I wondered the same thing. Certainly C is considered by many as being an essential language for people to know. At Penn State Great Valley, where I teach, we assume that all students are familiar with the language, since it is taught for the remedial programming course. wrp103 (Bill Pringle) ^(Talk) 23:37, 22 April 2007 (UTC)

I agree that C is very important for computing science in some sense, certainly at least as much as Fortran. I'm not sure what the use of the "importance" ranking is supposed to be; maybe to select a subset of articles for inclusion when making a CD? Anyway, I've changed it to "high" now. — DAGwyn 19:08, 23 April 2007 (UTC)

Compiler

What is the best compiler for beginners?

--Drnoitall.hello 04:33, 13 May 2007 (UTC)

The answer you get will vary depending on a number of things, depending on what you mean by beginners - beginner programmers or programmers starting to learn C. It also depends on what platform you are dealing with. Most Unix / Linux systems come with a C compiler, so that is probably the one to use. There are a number of C compilers for Windows - free and otherwise, so it depends on your budget. Probably gcc is the most common C compiler that will run on a wide variety of platforms. Turbo C is a commercial compiler used to be very popular. If you have Microsoft Studio, then you probably already have Visual C++, which is windows-oriented, but is generally acceptable for console applications.

It might make sense to include something in the article that addresses that question. wrp103 (Bill Pringle) ^(Talk) 11:46, 13 May 2007 (UTC)

Source language = C formatting

The recent change to the formatting of the examples results in really ugly presentation (at least under Firefox on Solaris). The coloring and emboldening seems to be applied capriciously; e.g. in "extern int" the extern is in bold but int is normal. Strings are in red for no apparent reason, and the shade of green used for preprocessor directives is hard to read. I suggest that this be changed back to the former style. — DAGwyn 16:39, 16 May 2007 (UTC)

Agreed. This looks hideous. –Henning Makholm 21:10, 16 May 2007 (UTC)

I agree, and have reverted to before the formatting changes. -- wrp103 (Bill Pringle) ^(Talk) 22:12, 16 May 2007 (UTC)

Maybe this would be a reason to try to improve the lang=C style itself, instead of completely dropping it? — Isilanes 08:50, 17 May 2007 (UTC)

What's there to improve? The <pre> style is perfect for showing code examples. Anything that diverges from it will be a loss. –Henning Makholm 18:16, 21 May 2007 (UTC)

Agreed. Plain courier text has been used for ages and people are used to it. If we were to use the style guide, we would run the risk of pages looking uglier and uglier with little or no warning. At least everyone agrees what <pre> should look like. ;^) -- wrp103 (Bill Pringle) ^(Talk) 19:09, 21 May 2007 (UTC)

Well, I personally think syntax highlighting is a great idea. I think it's pretty logic to assign different colours to different kinds of words. The only reason the green is hard to read is because of the grey background color. Maybe this should be fixed, by replacing it with a darker green, or the background with a lighter grey. And "extern" is some kind of a keyword, right? "int" is a variable type, right? So it's two different words. Two different colours. Makes sense here. Also, maybe your gamma balance is not set correctly. --Ysangkok 19:17, 29 June 2007 (UTC)

"extern" and "int" are both keywords. Some of us find the highlighting distracting, even if it weren't quite so unaesthetic. (My gamma balance is fine.) Note that coloring is not part of the C language, so presenting C programs using colors is misleading anyway. — DAGwyn 17:58, 1 July 2007 (UTC)

There are probably arguments for and against syntax highlighting, especially for those who have only used IDEs that use such conventions. The problem I have with it is that there is no convention that all can agree upon. One problem with colors is that it can pose problems for people who are color blind, and when printed, the color might go away. I can see an argument for bold text to indicate reserved words, but at the same time I don't see any real reason to use anything other than the standard <pre> tag. -- wrp103 (Bill Pringle) ^(Talk) 23:32, 29 June 2007 (UTC)

My main objection is that formatting is not part of the language. I'm fine with the tag used in any article other then the article on the language itself. Martijn Hoekstra (talk) 20:12, 12 December 2007 (UTC)

I agree; the C language standard does not specify fonts, colors, etc., and a standard-conformant compiler cannot recognize any such thing. No actual C source code (to my knowledge) has such styling embedded in it; you only see it as applied by some graphical environments (and they have had differing ideas about how to do it). In addition to other problems noted in previous comments, it is possible for a C program to in effect extend the language by defining macros and typedef names, such as has commonly been done for "bool" and "complex", making the distinction between built-in keywords and user identifiers artificial, misleading, and distracting. Indeed, "bool" becomes a keyword, in effect, when a particular standard header is #included and not otherwise. Similarly, "FILE" might as well be considered a keyword, although it isn't technically. Whatever rules somebody makes up for this kind of highlighting are certain to not suit others who have different ways of thinking about such categories. I have never seen a case (in IDEs I have used that apply such formatting) where code has been rendered more intelligible by colors and font styles. (Perhaps it might be of very slight assistance to somebody who has no knowledge of the language.) — DAGwyn (talk) 20:52, 12 December 2007 (UTC)

I have been programming in C (and various other languages) for over twenty years. I disagree with you in that I find that syntax-coloring (colors and fonts) does help (slightly) in seeing different classes of language elements. However, I do agree with you that since syntax-coloring is not specified in the language, and, additionally, there is nothing approaching a standard for syntax-coloring, it should not be used to highlight code in this article. It should probably not be used in other articles either. — Val42 (talk) 23:12, 14 December 2007 (UTC)

A New Article Added

I have added a link to a article abt c programming prerequiste knowledge.

Its a gigantic exhaustive article abt the things a top notch c programmer must have in his mind.

You can view it at http://www.cencyclopedia.com/Tutorials/Basic_Tutorials/Prerequisite_Knowledge.php

If possible please rate it. Also discuss its quality and quantity.

New Category of external links

Added a new category of external links for advance topics of applying C.

C is not only abt leaarning basics but also about building applications and games and other commercial viable softwares.

No, such programming is certainly not specific to C, and while the links may be useful to some we need to draw the line somewhere. If everything on the net involving C is linked into the C article, it would be massive! — DAGwyn 14:53, 24 May 2007 (UTC)

Games Programming Step By Step Tutorial

Added first 2 of many Games Programming Step By Step Tutorial in C.

These create tic tac toe and ping pong, first games ever to be developed for computers, remember ATARI.

These articles are targeted from begineers and to experts.

Though they are not very portable as most of the games are not, because of the graphic library and drivers used the software they use are easily available and tutorial provides all inforamtion neccessary.

This a step by step tutorial in which code is developed in step by step with the reader.

It also teaches many advance programming concepts.

They are design to iginite sparks of creativity in begineers C programmers and help them see how wonderfull and enjoyment filled world of games programming is.

Let them feel that it is far more fun to create them than to play them.

links to them are -

http://www.cencyclopedia.com/Tutorials/Games_Programming/TicTacToe.php http://www.cencyclopedia.com/Tutorials/Games_Programming/PingPong.php

Thanks You

Any comments are appreciated. —The preceding unsigned comment was added by 122.163.74.199 (talk • contribs) 18:22, 23 May 2007.

I reverted the links - please review WP:SPAM. (BTW - the links didn't work when I tried to look at them.) -- wrp103 (Bill Pringle) ^(Talk) 19:23, 23 May 2007 (UTC)

I beg to differ but link seem to be fully functional. I dont see your reason of not adding them. What would anybody will gain adding non functional links.

—The preceding unsigned comment was added by 122.162.70.140 (talk • contribs) 01:39, 24 May 2007.

Please sign your posts using4 tildes (~~~~).

The links timed out. Nobody would deliberately add bad links, but all links were to the same site, which is why I called it spam. -- wrp103 (Bill Pringle) ^(Talk) 02:05, 24 May 2007 (UTC)

Why isn't C in the category Procedural programming languages?

... For that matter, what about:

BASIC
C
C++
ColdFusion
COBOL
Component Pascal
D
Delphi
ECMAScript (e.g., ActionScript, DMDScript, JavaScript, JScript)
Forth
Lasso
Linoleum
Maple
Mathematica
MATLAB
Modula-2
Oberon (Oberon-1 and Oberon-2)
M
Python
VBScript

(Copied from the list on the page Procedural programming).

129.67.18.125 18:22, 16 June 2007 (UTC)

My guess is that the C article existed before that category was created, and whoever created it didn't bother to plant links in the obvious set of existing articles. Anyway, I have added some category links to the C article. — DAGwyn 20:10, 18 June 2007 (UTC)

Wish to add C Programming Website Link

Please take a while and review http://www.cencyclopedia.com and tell wether its worth enough to be added as link.

Thnk You. —The preceding unsigned comment was added by Cencyclopedia (talk • contribs).

I would say absolutely not. I call spam and conflict of interest, although I do appreciate that you took the time to ask rather than simply adding it in. However, I would also oppose the addition of the site, anyway. It adds little to the article, and I think that we should stick to either official or de facto 'standard' or 'official' sites there (and yes, that means that I disagree with some of the existing sites in there: comments from other editors on the existing links would be appreciate, before I just remove them — I mean, a personal website hosted on an ISP account?) Angus Lepper^{(T, C, D)} 15:16, 21 July 2007 (UTC)

I agree that the site should not be added. I would also have no problem if the current list were trimmed. -- wrp103 (Bill Pringle) ^(Talk) 16:33, 21 July 2007 (UTC)

Translation unit

The article translation unit talks about there's something called translation unit in the C programming language, and links to this article. May someone explain what translation unit means in the context of C? --Abdull 17:51, 23 July 2007 (UTC)

One source file, after all preprocessor instructions have been carried out (all #includes done, macros expanded, etc). Usually corresponds to one object file, that the linker combines with other translation units to resolve symbols etc before creating the final executable file. Angus Lepper^{(T, C, D)} 19:00, 23 July 2007 (UTC)

CR-LF

Is it worth making the distinction between carriage return and line feed in the text? At the moment it claims '\n' moves the cursor to the beginning of the next line (as opposed to a combination of '\r' and '\n') — which is indeed the case in some consoles (e.g. Windows command prompt), but by no means all (heck, even the Windows telnet program doesn't). Angus Lepper^{(T, C, D)} 13:43, 3 August 2007 (UTC)

The '\n' character simply sends a line feed to the output file. It is the O/S (or library routine) that changes it to whatever the local EOL sequence might be. For those operating systems, opening a file as "ob" turns off that option, while "ot" turns it on. -- wrp103 (Bill Pringle) ^(Talk) 15:10, 3 August 2007 (UTC)

The '\n' character is required (by the C standard) to delimit a text line; how that is done depends on the specific platform, and I have seen nearly a dozen different methods used, CR,LF being just one of them. I don't see any need for the C article to go into this any more deeply than it already does. — DAGwyn 17:39, 3 August 2007 (UTC)

"Hello, world" example

Shouldn't the 'standards compliant' form be something like:

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
	printf("Hello, world\n");
	exit(EXIT_SUCCESS);
}

One does not return from the main() function but rather exit()s. —Preceding unsigned comment added by 142.108.228.34 (talk • contribs) 19:51, 16 August 2007 (UTC)

Not sure who told you this, but they were wrong. Returning from main is perfectly acceptable. Dlong 20:10, 16 August 2007 (UTC)

I remember that classic Mac OS programs had to end with ExitToShell(), which did some housekeeping tasks. Most C implementations just used a macro to map exit() to ExitToShell(), and you could get some funky behavior in certain setups just returning. Another thing, what if some other part of the program called main()? Insane, I know, but still - it would return a value and continue(!). —Preceding unsigned comment added by 142.108.228.34 (talk • contribs) 20:28, 16 August 2007 (UTC)

That does not alter the fact that the program in the article is strictly conforming. And in fact all implementations are required to support "housekeeping" on a return from main (except on returns from recursive calls to main). For instance, functions registered with the atexit function must be called. Quoting from the C89 draft, "A return from the initial call to the main function is equivalent to calling the exit function with the value returned by the main function as its argument. If the main function executes a return that specifies no value, the termination status returned to the host environment is undefined." C99 makes a similar stipulation. Eric119 03:40, 17 August 2007 (UTC)

I'm convinced :) —The preceding unsigned comment was added by 76.10.148.186 (talk • contribs) 11:30, 17 August 2007.