Talk:C (programming language)/Archive 9

This is an archive of past discussions about C (programming language). 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 7

→

Any suggestion to improve?

I've added my website [1][c-programming-guide.com] to the tutorial session, but it has been removed. Any suggestions for me to improve my website? —Preceding unsigned comment added by 155.69.5.236 (talk) 14:08, 31 August 2007 (UTC)

In general, it is not proper for anyone to add their own web site to any article. -- wrp103 (Bill Pringle) ^(Talk) 05:56, 1 September 2007 (UTC)

originally used vs predominantly used

There has been a back and forth discussion about whether the intro should state that C was "originally used" or "predominantly used" for systems software. There is no doubt that C was originally used for systems software, but the question is if it is now "predominantly" used for systems or application software. The two citations following that sentence say that it was originally used for systems software, but I couldn't find any claim that it is now predominantly used for either.

It might be that C is now mostly used for applications, but until we can find a citation that makes that claim, it seems to me the sentence should use "originally." If we find a citation that says C is mostly used for application software, then I suggest that we change the sentence to:

Although originally<ref>original footnotes</ref> used for [[system software]], it is now predominantly<ref>new citation</ref> used for [[applications]].

Comments? -- wrp103 (Bill Pringle) ^(Talk) 15:57, 2 October 2007 (UTC)

You have misstated the issue. The intent of the sentence is to indicate what C is most useful for, and that is unquestionably systems programming, which is indeed what it was originally designed for. Of course it has been used for applications also, especially on early Unix systems which offered few viable alternatives (typically only Fortran and Bourne shell). These days, however, most apps are coded in higher-level languages such as Perl, PHP, TCL, and C++. C remains the predominant systems implementation language; more often than not those higher-level languages and their run-time libraries are themselves coded in C. C is heavily used for embedded systems development, especially for the scheduling/IPC/device/interrupt support.

The introductory sentence needs to convey this fundamental aspect of C usage. Your change to "originally" gives an impression that is contrary to the reality; it makes the reader think that although C started out being used for systems programming, its use has changed over time to mainly applications. Rather the opposite has occurred; while a significant fraction of C's use shortly after its invention was for apps, that fraction has become smaller in recent times, due in large part to the more convenient and effective facilities offered by higher-level languages.

If the references don't properly reflect this, then better references are needed, not a change to the text to give the reader a wrong impression. — DAGwyn 23:01, 2 October 2007 (UTC)

If somebody can find a reliable source that states whatever C is mostly used for, we can use it. I don't read the sentence the way you are interpreting it. I will tweak it to reduce that conception. However, I stand by the fact that the citation only states that C was originally used for system programming, and until we can find another citation, we can't state what it is usually used for today. -- wrp103 (Bill Pringle) ^(Talk) 00:35, 4 October 2007 (UTC)

I agree with wrp103 (Bill Pringle). Derek farn 07:21, 4 October 2007 (UTC)

I have further tweaked the sentence; hopefully it will now satisfy all interested parties. C has always been used for both systems and applications. It is certainly not the best choice for most modern applications, and has largely been supplanted by Perl, Python, C++, and other languages in that capacity. However, it remains very important for systems implementation, not having been supplanted in general in that area (despite having some deficiencies). My concern with the previous revisions is that they could easily have been read as saying "C was once used mainly for systems programming, but is now more often used for applications", which gives an entirely wrong impression. — DAGwyn 20:16, 4 October 2007 (UTC)

Array-pointer interchangeability error?

In the array-pointer interchangeability section, the four "equivalent" examples at the bottom are not necessarily equivalent, and do not attempt to demonstrate the same point as the rest of the section.

Contrary to what the example suggests, *(x + i) will result in an address (x + i*sizeof(*x)), whereas *(i + x) will result in an address (i + x*sizeof(*i)). Clearly, if sizeof(*x) and sizeof(*i) are not both equal to one, these will not be equivalent.

Also, I'm not even sure if this is really valid C (I can't get it to compile with either MSVC or gcc without casting), since "x designates an array". Either way, this example does not belong in this section. —Preceding unsigned comment added by 69.245.208.25 (talk) 04:25, 5 October 2007 (UTC)

The article text is correct. i+x does *not* result in an address i+x*sizeof(*i); subclause 6.5.6 of the current C standard explains what happens. The pointer operand is treated the same way in this regard, no matter which order the operands have. The example also strictly conforms to the C standard. I don't know why you didn't get it to work, but try the following strictly conforming program:

#include <stdio.h>
static int i = 3;
static double x[10];	/* x designates an array */
static void dump() {
	int k;
	for (k = 0; k < 10; ++k)
		printf("%g%c", x[k], k<9? ' ': '\n');
}
int main() {
						dump();
	x[i] = 1;	dump(); x[i] = 0;	dump();
	*(x + i) = 1;	dump(); *(x + i) = 0;	dump();
	*(i + x) = 1;	dump(); *(i + x) = 0;	dump();
	i[x] = 1; /* strange, but correct: i[x] is equivalent to *(i + x) */
			dump();
	return 0;
}

The example certainly does belong in the section, since it illustrates the exact meaning of i[x] in C, which is quite unlike most other languages. —Preceding unsigned comment added by DAGwyn (talk • contribs) 15:24, 5 October 2007 (UTC)

C99 Expanded to its own page

I am interested in expanding the C99 section to its own page and including code snippets. The one on this page can stay as is with a pointer to the new page for more details. Does that sound good to you? Daniel.Cardenas 22:00, 14 October 2007 (UTC)

What would be the purpose? Especially of "code snippets"? Of course, if there were to be a separate C99 page we would plant a link to it in the C page. — DAGwyn 05:04, 15 October 2007 (UTC)

Better more detailed explanation of C99 changes. Daniel.Cardenas 13:59, 15 October 2007 (UTC)

So I guess you'd want a link after the list in C99/New features? Note that apart from new features, there were very few substantive changes from the previous spec (C90). The main one worth noting is the removal of implicit "int" in declarations. ("long x;" is still OK, but "register x;" isn't.) — DAGwyn 16:07, 15 October 2007 (UTC)

Done. Chris Cunningham (not at work) - talk 10:22, 23 June 2008 (UTC)

Developer - Dennis Ritchie only ?

Well i believe that this was not only Dennis Ritchie. But also Ken Thompson who initiated and developed for example ++ -- unary operators with it's position relative application. In papers i read from Dennis there was Ken "everything" Ken "everywhere", well there are only 2 links to him. It feels to me like he is somehow forgotten, isn't he? Cc..aa..ll (talk) 10:14, 8 December 2007 (UTC)

The Bell Laboratories team that developed Unix discussed a lot of ideas among themselves, and a suggestion by one person might be developed by another. The initial development of C is generally attributed to Dennis Ritchie, with some later additions due to Steve Johnson. Ken Thompson changed to C instead of assembly language for the Unix kernel only after structures were added to the language. Thompson is given primary credit for developing Unix; he also was co-developer of the chess machine Belle and produced the kernel for Plan 9. — DAGwyn (talk) 19:06, 10 December 2007 (UTC)

I should add that Dennis Ritchie co-developed Unix, primarily its I/O components. — DAGwyn (talk) 21:02, 12 December 2007 (UTC)

My C book tells me that "C was the language that was being written to write Unix in, and the developement of each had a strong impact on the other" (paraphrasing, can't find the book). Ofcourse, that may be really wrong, but that's what's roughly there. Martijn Hoekstra (talk) 21:07, 12 December 2007 (UTC)

Several versions of Unix were written (developed) before C existed, and the early Unix kernels were written in assembly language (first on the PDP-7, then on the PDP-11); see the history in the Unix article. The only general-purpose programming languages supported in the first edition of Unix were assembly language, B, a dialect of Basic, and a subset of FORTRAN. P. J. Plauger developed a "super-assembler" for the PDP-11 contemporaneously with Ritchie's development of C; both of these were meant to better support systems programming. B, which might have served in this capacity, had the problem of being entirely word-oriented, so it was unable to effectively exploit the PDP-11's byte-oriented features. As I mentioned previously, once data structures ("struct" types) were added to C (as it kept evolving), Ken decided to recode the Unix kernel into C. There is no doubt that due to the close proximity of these workers there was much interaction among them (as I noted previously); however, specific portions of the Unix environment were the responsibility of particular individuals, who made the design decisions and personally coded the products. Thus, C belonged to Dennis, and most of the Unix kernel (excluding I/O components) belonged to Ken. In "user space", the various commands, utilities, libraries, etc. belonged to various people; for example there were several early attempts at what eventually became the "standard I/O library"; one due to Mike Lesk, with Dennis providing the one that eventually prevailed. — DAGwyn (talk) 22:21, 12 December 2007 (UTC)

I will add that Ken was the original developer of the B language, but its role in the evolution of C starts with the B compiler that Dennis wrote; see the B article for more about the history. Much of C's syntax was inherited from B, and its influence is noted in the C article. — DAGwyn (talk) 23:32, 12 December 2007 (UTC)

Wow, thanks for all the infomation. Though not exactly what talkpages are meant for, it was a rather good read! Martijn Hoekstra (talk) 23:33, 12 December 2007 (UTC)

So what did Kernighan do ? Reg nim (talk) 18:17, 13 May 2008 (UTC)

Kernighan has written a number of books about C and Unix, including K&R. He also contriuted to Unix, including awk, nroff and troff. -- wrp103 (Bill Pringle) ^(Talk) 22:45, 13 May 2008 (UTC)

Many thanks. Reg nim (talk) 11:47, 14 May 2008 (UTC)

Closures?

In the section "Characteristics" is the phrase "function pointers allowing for a rudimentary form of closures and runtime polymorphism." I'm pretty certain that it's not possible to call these function pointers "closures." A closure (computer science) is defined as a function combined with a context or environment. Since C doesn't allow nested functions (extensions to the standard excepted), a traditional closure is not possible without trickery like (ab)use of the the preprocessor, or an explicit passing of variables to the function. I could be mistaken here, but I don't think so. I'd really like to change that sentence to be more correct. Any suggestions? Foolingmachine (talk) 03:22, 11 January 2008 (UTC)

It doesn't say that function pointers are closures, it says they can be used in implementing a rudimentary form of closures, which seems to be correct. It may also be necessary to employ static variables (corresponding to "bound" variables). I don't think there is any need to revise the wording. — 158.12.88.57 (talk) 18:07, 11 January 2008 (UTC)

That is true, and I see your point. I still think the wording could be revised, as it doesn't give any explanation of how this is possible, nor is this common knowledge (I'd venture that the majority of C programmers don't know what closures are anyway). Another issue I take with the phrasing is that I commonly see anonymous functions mistakenly called "closures." I don't want to further propagate that mistake. I do recognize I'm hardly an authority on the matter, of course. Foolingmachine (talk) 09:57, 12 January 2008 (UTC)

It is fairly common for OS or library APIs to allow the user to pass a callback function and a void* that will be passed to the callback when it is called. Most experienced C programmers will have seen one or more of those, even though they don't know that what they're doing would be called a "closure" if there were language support for doing it more transparently. It is not too far off to describe it as "a rudimentary form of closures", I think. Also it is not clear to me who you think the article supports the notion that closures means anonymous functions, when C does not have anonymous functions at all. –Henning Makholm 21:49, 12 January 2008 (UTC)

Again, fine points. From a functional programming standpoint, it simply seems highly odd that such a sentence is included with virtually no explanation whatsoever. It is not a common way to refer to C function pointers, even if the essential pieces are there (your void* could certainly be considered a method of passing the necessary context, but it's stretching the definition, I think). After all, none of the explanations presented on this talk page appear in the article. As for the "anonymous functions" bit, I wasn't very clear or correct—the bottom line is that closures are commonly misunderstood, and this phrase doesn't really provide any useful information. I can still see no valid reason to include it in the article, at least in the current form. Foolingmachine (talk) 03:14, 14 January 2008 (UTC)

I agree that it is strange for the sentence to be there; it would be better for the article to describe what function pointers are than to hint obliquely what they may be used for. (However, again, I don't think that the strange sentence claims that function pointers can be referred to as closures, only that they can be used as one of several building blocks for implementing closures. Don't you see the difference between those?) –Henning Makholm 03:24, 14 January 2008 (UTC)

As I recall, the bit about "closures" was already present before I started editing this article. I don't see the necessity to mention it, but presumably the original proponent had his reasons. — DAGwyn (talk) 05:10, 13 January 2008 (UTC)

I spotted this prior to reading this Talk and fixed it. The text really did seem to be claiming that function pointers are primitive closures. Though it's hard to pin down an exact definition of a closure, it has to do with the construction of a run-time object that encapsulates access to a captured lexical environment, plus code. C function pointers are the code only. You can't use C pointers to do closures, period; there is no standard-defined access to the lexical environment. Thanks to Turing equivalence, you can emulate the behavior, which isn't the same thing as expressing it. The page is already several times longer than a proper article, so there is no need to get into details about what features of other programming languages can or cannot be emulated using function pointers. A C example of emulating closures with function pointers might be appropriate in the Wikipedia page on closures, to which this article could point.

Relation of {} to set theory?

I always felt it is taken or inspired from here. It helped me to lear a C language (Anyway it is used for for example ordered set of statements, ordered set of "data structures" in declarations ... ). I recently ran into discussion that those 2 symbols have nothing to do with set theory. Could someone correct this? Xchmelmilos (talk) 22:33, 26 February 2008 (UTC)

In mathematics,

\{\}

are used for sets -

\{1,2,3\}

is the set containing 1, 2 and 3;

\{x\in \mathbb {R} \ |\ x>0\}

is the set of positive reals, etc.

In C however, braces are not used for sets, just compound statements and initializers, etc... but Oberon does use braces for sets (and BEGIN and END for blocks) and Pascal uses braces for comments.

Alksentrs (talk) 15:20, 28 February 2008 (UTC)

There is a kind of set-like use of braces in structure declarations, but really it is better thought of as a syntactic grouping construct than anything else, for C. —Preceding unsigned comment added by DAGwyn (talk • contribs) 17:34, 29 February 2008 (UTC)

The { } symbols can be used to define an array of elements (not a set) like this: int a[] = { 1, 29, 6 ,8 }; L337 Krew (talk) 13:43, 7 May 2008 (UTC)

Yes, that may have inspired their use in initializer lists, but not for compound statements. — DAGwyn (talk) 20:24, 8 May 2008 (UTC)

Also keep in mind that braced sets in modern math notation are unordered, whereas everything you put braces around in C is ordered, so this is a misleading analogy. There's certainly no basis for claiming C was designed with this analogy in mind. Dcoetzee 21:53, 8 May 2008 (UTC)

You're loony. C braces have next to nothing to with sets, semantically. I can't fathom what sort of learning difficulty with C could possibly be resolved by identifying braces with set notation. Gee, you know, I'm an astronomer. A double-pointer int (**x)(void) looks like a binary star system, which is something warmly familiar and helped me learn C ...

Archive 2 created

All the discussions had died off, and the page was way too long. — DAGwyn (talk) 00:38, 15 April 2008 (UTC)

I've gone through the archives and split them into reasonably-sized chunks. Thanks to the lack of housekeeping in the early days the first 4 pages or so are very poorly chronologically ordered (the very earliest discussion is on pages 3 and 4), but at least it's feasible to read through the old discussion now. I'll try to stay on top of this in future. Chris Cunningham (not at work) - talk 09:49, 1 May 2008 (UTC)

"Blather" and article introductions

So for the second time the tooshort tag was removed from the article with the addition of a "blather" which reads, in its entirety:

This article traces the evolution of C and describes its characteristics.

In addition, the summary for the edit made this observation:

The ToC serves just fine as a detailed article preview

This demonstrates a misunderstanding of WP:LEAD, and of the makeup and function of introductiory sections in Wikipedia articles in general.

Quoting from the summary of that style guideline:

The lead should be able to stand alone as a concise overview of the article. It should establish context, summarize the most important points, explain why the subject is interesting or notable, and briefly describe its notable controversies, if there are any.

The purpose of the lead section is not to serve as a foreword, or to describe in terms of the encyclopedia itself what the article is about. It is to serve as an effective summary and overview of the article's key points, such that reading the introduction provides one with a reasonable high-level understanding of the subject matter as if one had skimmed the article itself.

In this capacity, the current lead is inadequate. Beyond providing context (a literal description of what the article defines), it provides only one sentence to capture the importance of the language in its field. For an article of this length, we should be aiming for three paragraphs which provide a concise but complete summary of the article's key points without explicitly saying that the user has to read the article for further detail.

If we can't get this sorted out shortly, the article should be re-tagged so that it is adding to the appropriate cleanup category. That lets users interested in cleanup tasks know that there's work needed here. Chris Cunningham (not at work) - talk 10:57, 1 May 2008 (UTC)

The problem is, when in the past the lead included other (factual) "orienting" statements such as "C is one of the most widely used programming languages", proponents of other PLs (and critics of C) jumped all over it. The current lead is a compromise that was worked out long ago and it has remained very stable since then. It does perform the essential functions of a lead: it defines the subject, it explains its significance in the world, and it states the scope of the article. I see no point in trying to turn it into a "capsule article", since the text would become unintelligible if significantly abridged for that purpose. — DAGwyn (talk) 16:11, 1 May 2008 (UTC)

I could go either way. I think for C a short introduction is sufficient - but the current introduction surely understates the impact of C of both industry and research. As for critics of C "jumping all over it," I wrote the original criticism section on C and would still advocate an introduction emphasizing its impact. Dcoetzee 17:24, 1 May 2008 (UTC)

Thanks for the commentary. I suggest we work on an expanded introduction in this Talk page until a mutually acceptable version results. — DAGwyn (talk) 23:15, 2 May 2008 (UTC)

Update

I've done some minor expansion which provides a skeleton for further work. Chris Cunningham (not at work) - talk 12:49, 22 June 2008 (UTC)

Upper case

Mdsawyer58 has twice changed the identifiers in the original example

long int SomeFunction();
/* int OtherFunction(); */

/* int */ CallingFunction()
{
    long int test1;
    register /* int */ test2;

    test1 = SomeFunction();
    if (test1 > 0) 
          test2 = 0;
    else 
          test2 = OtherFunction();

    return test2;
}

to e.g. some_function on the grounds that "Historically, as stated by K&R in "The C Programming Language" manual (pg 33), uppercase is used for symbolic constants. I believe this page should be presented historically accurate." This reflects a couple of misunderstandings, which I will explain here in the hope of averting an editing war. K&R was talking about constructs like #define MAXLINE 80, where indeed all-upper case is used for a symbolic constant. That does not by any means imply that upper-case characters must not appear anywhere else in source code! It might be taken as implying that identifiers consisting solely of upper-case characters ought not to be used for anything other than symbolic constants. The above example does not violate any of these conventions. (Indeed, it illustrates a common and useful C style that is even more widely used in C++ and Pascal. It is good from the point of view of exposition to show that C identifiers, for variables and functions in this example, are not limited to lower case.) Note also that the example is valid as-is under the C compilers available at the time K&R was published, and was newly invented for this article. Therefore there is no error with regard to "historical accuracy." — DAGwyn (talk) 18:33, 11 July 2008 (UTC)

CSS

I noticed that CSS was added to the list of languages influenced by C in this edit. CSS is a markup language, and its syntax is quite different from C. Is there any reference to support the influence of C here? Papa November (talk) 18:31, 27 July 2008 (UTC)

I doubt it. I've removed it for now; we don't need to keep dubious information around while a reference is found. Chris Cunningham (not at work) - talk 19:49, 27 July 2008 (UTC)

Picture

What happened to the picture of the K&R C programming book in the summary box at the top of the page I didn't see it in the revisions at all --Melab ^±1 21:33, 9 September 2008 (UTC)

As I recall, somebody decided that it didn't meet Wikipedia requirements for photographic images, i.e. it wasn't copyright-free. — DAGwyn (talk) 00:04, 13 September 2008 (UTC)

Why is the 2nd edition shown, without mentioning earlier versions? I have the 1st edition (printed in 1978), as well as copies of the earlier "Reference Manual" which was an on-line file. (I also have some X3J11 notes, from when I was an Observer Member.) Should I try to include some of this stuff in Wikipedia? Tripodics (talk) 23:51, 29 March 2009 (UTC)

Howcome no syntax highlighting?

Not a very important point, but surely we should be using the <source lang="c"></source> tags in this article, otherwise why does Wikipedia have support for them? Was there a previous discussion on this? --Huffers (talk) 17:55, 27 September 2008 (UTC)

Ah, found it. I'm amazed people were against it. Given the most popular IDE's and text editors used for coding C all have syntax highlighting on by default, you'd have thought this would imply that most people find syntax highlighted code easier to read. --Huffers (talk) 18:08, 27 September 2008 (UTC)

Not everyone - it appears to be a preference rather than an absolute rule. It's been discussed several times (and see that there are several people to convince). Tedickey (talk) 18:41, 27 September 2008 (UTC)

Perhaps this article should have an editnotice to inform anyone editing it about the current consensus on source tags, so they don't keep getting put in and then reverted? Joseph Myers (talk) 20:05, 27 September 2008 (UTC)

While were on the subject, why is this exclusive to C? The same things could be said about most programming languages(if not all). Mike92591 (talk) 21:02, 27 September 2008 (UTC)

I'd suppose that making it a settable user preference would make more people happy with it - but look at the mess with dates, which are settable in principle. Tedickey (talk) 21:26, 28 September 2008 (UTC)

The main arguments against lang=c source tags are (a) the result looks horrible! in many browsers; (b) readability is actually reduced when more information is visually presented; (c) color is not part of the language; (d) such tags are of no value to a competent C programmer. For small code examples, whatever benefit is claimed for the coloration cannot be very significant anyway. — DAGwyn (talk) 10:38, 9 November 2008 (UTC)

Absent features

This really could go on and on. I think it would make more sense to just say what its features are. Mike92591 (talk) 20:17, 28 September 2008 (UTC)

Actually the list is a meager remnant of the now-vanished Criticism of C (programming language) article. It serves a useful purpose under the section on Minimalism. — DAGwyn (talk) 10:41, 9 November 2008 (UTC)

operators

operators explain in c language —Preceding unsigned comment added by 164.100.6.50 (talk) 10:24, 7 October 2008 (UTC)

I guess you're looking for Operators in C and C++. Alksentrs (talk) 11:43, 7 October 2008 (UTC)

Somebody removed the section that listed them, which I have now restored (it contains the link mentioned above, which goes into more detail). — DAGwyn (talk) 10:46, 9 November 2008 (UTC)

Added first line

i added first line because the first line is very well not a good beginning. The beginning should be an introduction to comp language C.Albertgenii12 (talk) 21:16, 21 October 2008 (UTC)

"Array types in C are always one-dimensional"

Surely this is just wrong. I just wrote a little program to check I wasn't going mad and prove that you can have 2+-dimensional arrays in C. And it works:

[BTW No-one need bother pointing out the lack of variable initialisation!]

#include <stdio.h>

typedef char array[10][10];

void main(void)
{
array test;
int x,y;

for (x=0; x<=9; x++)
{	for (y=0; y<=9; y++)
		printf("%3d ",test[x][y]);
	printf("\n");
}
}

RobertSteed (talk) 16:30, 18 November 2008 (UTC)

Read a bit further down. "C does not have a special provision for declaring multidimensional arrays, but rather relies on recursion within the type system to declare arrays of arrays, which effectively accomplishes the same thing. The index values of the resulting "multidimensional array" can be thought of as increasing in row-major order." I'm skeptical about this interpretation, but without carefully consulting the standard I'm not prepared to contest it. Dcoetzee 21:29, 18 November 2008 (UTC)

I did read that, and it too is wrong. Again, see my example - that is a multidensional array, in standard C code. It is not an array of arrays.

RobertSteed (talk) —Preceding undated comment was added at 11:26, 19 November 2008 (UTC).

Your example is wrong.

That is an array of arrays.

Consider what sizeof test[x] means. —Preceding unsigned comment added by 216.239.45.4 (talk) 11:41, 1 March 2009 (UTC)

It is a matter of interpretation. However often used, an array in C is veneer ("syntactic sugar)" over plain pointer arithmetic. The way it handles multidimensional arrays is to extend that pointer arithmetic. So, in fact, C does not have any special provision for multidimensiaonal arrays. However, as far as I'm concerned, the same could be said for one-dimensional arrays in C. I see no point in the statement saying "they're always one-dimensional". I'm for deleting that. --A D Monroe III (talk) 12:11, 19 November 2008 (UTC)

Me too - you might as well say C doesn't really have array indexing, since it's just syntactic sugar for pointer arithmetic and dereferencing. It was designed to support multidimensional arrays in this way. Dcoetzee 20:40, 19 November 2008 (UTC)

The array indexing operator [] is just veneer over pointer arithmetic. Arrays themselves are not. Eric119 (talk) 00:25, 20 November 2008 (UTC)

Eric119 is right; and furthermore, the fact that C arrays are inherently one-dimensional is important for a programmer to understand, as it affects function parameters (for example). — DAGwyn (talk) 17:53, 6 May 2009 (UTC)

As a side note, it is important to see that there is a difference between a 2 dimensional array like char arr[10][10] (which does rely on recursion), and a 2 dimensional array where the first dimension is an array of pointers to the second dimension. A good example of the latter is argv (the 2nd argument to main, the argument vector). The simple 2 dimensional uses less memory, and is generally consecutive in memory - the second uses more memory (the size of the first dimension) and may or may not be consecutive in memory Ajrisi (talk) 13:01, 12 May 2009 (UTC)

POV-based comments regarding object-orientation

The C language doesn't provide built-in support for object-oriented code (nor in fact for several interesting features), though those can be constructed. There are well-known examples of class-structures in C, e.g., X Window System. It would be nice to reduce the persistent intrusion of POV-based edits in this area. Tedickey (talk) 20:06, 11 December 2008 (UTC)

I did not edit any of the article in regard to this area, but I don't agree with you. The current version of the article says: Very limited support for object-oriented programming with regard to polymorphism and inheritance. There is no built-in support at all, I would prefer a sentence like: No built-in support for object-oriented programming. This would be more accurate IMHO. It's the same for generic programming. With C you can do anything you want (C is a very powerful general purpose low-level language), but as C is intentionally "close to the metal", you doin't have much help for any high level constructs such as Object Oriented Programming, Generics, Closures, Garbage Collection, etc... It does not mean that you can not develop frameworks in C to support these features. Hervegirod (talk) 12:51, 17 January 2009 (UTC)

open standard

It is kind of curious to see C# in the open standard article, but not C.

Is there a reason for that ?

If not, could someone who knows a bit about the subject add it there ?

Current C standards apparently don't meet the criteria. Generally, you have to buy a copy, and that's cheaper for some national-body versions than for others. I don't know whether the next C standard (C1x) will qualify as an "open standard." — DAGwyn (talk) 17:58, 6 May 2009 (UTC)

Image copyright problem with File:Kr c prog lang.jpg

The image File:Kr c prog lang.jpg is used in this article under a claim of fair use, but it does not have an adequate explanation for why it meets the requirements for such images when used here. In particular, for each page the image is used on, it must have an explanation linking to that page which explains why it needs to be used on that page. Please check

That there is a non-free use rationale on the image's description page for the use in this article.
That this article is linked to from the image description page.

This is an automated notice by FairuseBot. For assistance on the image use policy, see Wikipedia:Media copyright questions. --13:49, 8 February 2009 (UTC)

Pointer alignment

Regarding my addition reverted in rev. 274795659, is not the reference to the WG14 year 2005 draft of the C standard sufficient to substantiate my re-phrasing of the actual paragraph 7 of section 6.3.2.3? --ilgiz (talk) 23:55, 3 March 2009 (UTC)

The editor who reverted seemed to think that your description was not faithful to the standard.

It is difficult for me to understand your paragraph; you say that the C standard requires such-and-such, but it is not clear whom it requires it of. Is it something a C implementation must make sure happens, or something a programmer must construct his program to conform to? It's not easy to tell from your text, unless one already knows what you're trying to say.

Also, it is not clear to me that the issue is one that ought to be discussed in this article at all. It is not my any measure a central property of the C programming language how it deals with unaligned pointer casts. Language lawyers and professional programmers who care about the theoretical limits of portability need to know these things, but they need to know many more details than a general encyclopedia article can reasonably provide anyway. Everyone else will probably go "huh?" no matter how well this is explained. –Henning Makholm (talk) 01:06, 4 March 2009 (UTC)

I read your comment as a concern that it is up to the C compiler implementation to go into necessary details of targeted CPUs. But I think the standard had to be adjusted so that it would apply universally. You may already know that some CPUs require word access to occur by an aligned boundary and that the compilers targeted to such CPUs provide ways to adjust the code to the CPU specifics. For example, armcc offers the following measures:

stack variable alignment on a boundary of multiple of 8,
the __packed qualifier that would make the compiler access adjacent words and combine them into a result,
the __align(n) keyword that forces alignment on a multiple of "n".

I think that following the pointer alignment restriction I found in the C standard draft would allow to write portable code. For example, to make the anti-example portable,

char *external_buffer = "abcdef";
uint32_t *internal_data;

internal_data = (uint32_t *)external_buffer;  // UNDEFINED BEHAVIOUR if "the resulting pointer is not correctly aligned"
// Also, *internal_data results in different values on big- and little-endian CPUs.

I would write:

char *external_buffer = "abcdef";

// Apparently, it goes without saying that automatic and static variables are guaranteed to be correctly aligned
uint32_t internal_data1;
uint32_t *internal_data = &internal_data1;

// Alternatively, section 7.20.3 "Memory management functions" guarantees that malloc() returns an address of a super-aligned block
// uint32_t *internal_data = malloc(sizeof(uint32_t)); 

// assuming the network order of the external data and that the protocol stipulates a 4-byte field in the beginning
*internal_data = (((((uint32_t)(external_buffer[0]) << 8) | external_buffer[1]) << 8) | external_buffer[2]) << 8) | external_buffer[3];

It is good that the article can be an educational material. I do not mind if it also presents minor details reflected in the C standard. --ilgiz (talk) 16:12, 4 March 2009 (UTC)

I think there are several misconceptions in the above. The C standard does not currently include any specific object-alignment aids, and implementations are always required to align the standard types so that they work (which is one reason structs can have internal padding).

It is certainly true that a few target-specific applications need some additional form of alignment control, for example aligning DMA buffers with memory cache lines; in such cases, compilers for those targets virtually always provide nonstandard extensions to do the job.

Alignment of word pointers on sub-word boundaries cannot be supported on many platforms without a high run-time cost for using that facility, and since it is rarely useful (only for picking fields out of a packed record image, which may also have endian issues) the C standards committee has been reluctant to require it be supported by all implementations. — DAGwyn (talk) 18:10, 6 May 2009 (UTC)

Re: "in such cases compilers for those targets virtually always provide _nonstandard_ extensions to do the job", I only touched on the case when a programmer casts a pointer of granularity 1 to another pointer of higher granularity. I suggested that this often stems from unawareness of the C compiler varieties and targets and of the C standard's section 6.3.2.3, par. 7 that prohibits such casts. I suggested that the cast should be replaced by allocating a properly aligned buffer of the higher granularity and by populating its content. Optionally, I suggested that it might make sense to combine the content transfer with the network-to-host order conversion.

Re: aligning hardware buffers, I am not experienced with this much. If the problem is in creating a buffer with a certain granularity that exceeds the particular C compiler/target's notion of super-alignment in malloc(), it is still possible to allocate a sufficiently large buffer and calculate the low and high addresses satisfying the required granularity. This would keep the code C standard compliant as it would not depend on non-standard keywords.

Re: impossibility of casting "sub-word" addresses to "word" pointers within C standard, this agrees with the above reference to section 6.3.2.3 par. 7. I understand that certain compilers do provide non-standard keywords such as __packed that tell the compiler to generate 2 word accesses, combine the results into one temporary word by rotating/masking these results and resolve *wordP into that temporary word. I am just saying that instead of relying on non-standard features and C preprocessor branching by target, it is possible to write portable bare C code by picking "sub-words" explicitly and putting them into a "word"-aligned buffer. --ilgiz (talk) 22:17, 8 May 2009 (UTC)

"C has a formal grammar"

If the "printed copy" referred to by the description of rev. 281338283 is the "Annex A (informative): Language syntax summary" section of the current standard WG14/N1256, one could mention that section as a reference. I guess the formal grammar does not define the language, its environment and its library, but only serves informative purpose. --ilgiz (talk) 19:16, 2 April 2009 (UTC)

It takes more than a grammar to define a programming language. C does have a formal grammar, but so does virtually every PL. The grammar in the Annex of the standard is derivable from the specifications scattered through the body of the standard. — DAGwyn (talk) 18:15, 6 May 2009 (UTC)

C# not mentioned as related

I don't want to edit this, in case the consensus is that it is too far removed, but I believe C# is based on C++ therefore should be mentioned as a "related language" to C, which started it all. The C# article does say this.KoolerStill (talk) 11:17, 23 April 2009 (UTC)

Huh? "C has directly or indirectly influenced many later languages such as Java, C#, Perl, PHP, JavaScript, LPC, and Unix's C Shell." Chris Cunningham (not at work) - talk 11:58, 23 April 2009 (UTC)

no link to C functions list??

There is a List of C functions with a separate article on each function. I can't see a link to this from this article. Is this deliberate? or is the list destined for deletion? I think it might be a little too detailed for an encyclopedia, but if it is there it should be linked to the main article on the language.KoolerStill (talk) 11:58, 23 April 2009 (UTC)

There are some well-established standard C library functions (currently subsetted for standalone implementations). Beyond that, there are C interfaces to other functions with varying degrees of standardization, and most programmers need to use some of them too. Since the page you mentioned mixes these together, and has many broken links, it doesn't merit inclusion as a reference here. The C article should no more be a master link page for everything related to C than the Oxygen article (if there is one) should link to articles about everything containing oxygen. — DAGwyn (talk) 18:22, 6 May 2009 (UTC)

That's partly why I was wondering about the usefulness of that list. Being a list, it offers no explanations, not even of what library function are. Yet in the article, where that is explained, there is no reference to the list, so the list seems to be orphaned. And more appropriate to a programming handbook than an encyclopaedia. Maybe I'm on the wrong talk for this concern? KoolerStill (talk) 20:41, 8 May 2009 (UTC)

Imperative vs. procedural

In the infobox next to “Paradigm,” C is tagged as being an “imperative (procedural)” programming language. Why are these two attributes not listed separately and independently (i. e., simply separated by commas, rather than one being in parentheses)? Does being either necessarily imply the other, or, conversely, is it impossible to be one but not the other? I’m not a programming language expert, and therefore would like clarification from one of the article’s authors. Thanks! —Technion (talk) 16:36, 2 May 2009 (UTC)

A procedural language is a particular kind of imperative language. Another would be an OOP language (in the C++/Java style). Alksentrs (talk) 16:45, 2 May 2009 (UTC)

According to the Wikipedia article on “Structured programming,” structured programming can also be considered a subset of procedural programming, and yet the tag “structured” is written independently, separated by a comma; according to your logic, the tag would then have to be double-parenthesized and written as “Paradigm: imperative (procedural (structured)).” Why the inconsistency? —Technion (talk) 17:01, 2 May 2009 (UTC)

Interesting point... I think that whilst you can use structured programming in C, it wasn't specifically designed for only structured programming: it has the goto statement, for example. Alksentrs (talk) 17:33, 2 May 2009 (UTC)

The definitions here are quite vague. I was taught in the end of 80's that procedural languages specify algorithms (the procedures leading to results), while non-procedural languages specify goals (SQL and Prolog, for examples, unless you delve deeper into SQL procedural extensions or use Prolog in procedural style). From my point of view, the situation is quite the opposite: Imperative languages (those based on visibly modifying a global state in the course of a computation) are a sub-group of procedural languages. But as I said, the definitions are quite vague. 85.70.62.27 (talk) 17:26, 7 June 2009 (UTC)

Enum deficiency

Without resorting to X-Macros, a C programmer cannot loop across enum values. In the best case, when the minimum and the maximum values for the enum are known and when there are no holes in the definition, a regular for loop will result in a warning that the condition is always true. I wonder if this may theoretically cause a run-time exception or lock-up with C implementations that insist on enum value consistency.

  e_t evar;
  for (evar = e_first; evar <= e_last; evar++) {
    ...
    continue;
    ...
  }

This best-case scenario could probably be rewritten as follows.

  e_t evar;
  for(evar = e_first; ; evar++) {
    ...
    goto next;
    ...
  next:
    if (evar == e_last) {
      break;
    }
  };

--ilgiz (talk) 21:35, 4 May 2009 (UTC)

Please use this page only to discuss possible edits to the C article, not for programming issues. The C "enum" facility was never meant to provide a compact set that can be iterated over. It was really meant as an alternative to #defined constant names as values of tag fields, and that was largely because it was nicer when using some (really old) debuggers, which would display the names for enum constants but not for cpp macros. — DAGwyn (talk) 18:30, 6 May 2009 (UTC)

This is almost true. The enum facility is an alternative to macro constants, but additionally provides a way of bounding acceptable values. For example, a function that takes an enum type as an argument enforces passing only values that are part of the enum, in comparison to a function that must take an int (or long, or whatnot) because the macro is typeless. Ajrisi (talk) 13:00, 12 May 2009 (UTC)

While it is not necessarily good practice to iterate across an enum (because enum values are not always consecutive), a common way of doing it is to have the last value in the enum be something like "MY_ENUM_END" (with MY_ENUM being changed to something more specific). Once that has been done, its fairly easy to use a common 'for' loop. Your code above (2nd part), by the way, is exactly the for loop:

  for(evar = e_first; evar != e_last; evar++) {...}

Remember, whenever possible, avoid goto's like they are the plague. Ajrisi (talk) 13:00, 12 May 2009 (UTC)

Thanks, ajrisi. Your correction is much shorter but needs to change the enum definition as you mentioned. Going back to my notation, your correction requires adding an artificial boundary element e_past_end to the enum definition, so the condition should look like evar != e_past_end. One cannot get by just writing evar != e_last + 1 as (a) I am not sure about C standard's limitations on arithmetic operations with enum values and (b) e_last + 1 might theoretically cause a run-time error. --ilgiz (talk)

Spot on - I left it as e_last, assuming that would be his name for what I called MY_ENUM_END. as for != e_last +1, you could do that, if you were sure that the enum values were consecutive, and that e_last+1 did not occur earlier in the list. Here is an example that the e_last + 1 would have trouble with:

 enum {
   E_FIRST = 0,
   E_SECOND = 2,
   E_LAST = 1
 };

You can see that the code would prematurely quit when it did the (evar != E_LAST+1). While it certainly wouldn't meet any form of coding standards, you always have to think "it could happen". Oh, before I forget, enums are internally stored as integers in the C standard (ISO/IEC 9899:1999 6.7.2.2 - The expression that defines the value of an enumeration constant shall be an integer constant expression that has a value representable as an int ) Ajrisi (talk) 13:00, 12 May 2009 (UTC)

I made a couple of changes to the above convo., changing the anonymous edits to show they were written by me. I did indeed write them, I just wanted people to know who to blame later if I was wrong. Thanks - Ajrisi (talk) 13:00, 12 May 2009 (UTC)

why not lang="c"?

Hidden editor comment in article: "Also, present consensus is against lang="c". " May I ask why? Isn't syntax highlighting a good thing? I can see turning it off for the outdated K&R example, but why is it off for the normal "Hello World!" example? --Cybercobra (talk) 23:57, 10 May 2009 (UTC)

Past discussions:

Alksentrs (talk) 01:46, 11 May 2009 (UTC)

Personally, I don't like syntax highlighting but, those really aren't good reasons. Mike92591 (talk) 21:17, 11 May 2009 (UTC)

Agreed. It's time to re-think this. If the lang attribute results in poor presentation in certain conditions then that should be brought to the attention of the MediaWiki developers, not hacked around on one of our highest-profile programming language articles. It's there for a reason, and we should use it to provide the greatest semantic value for our readers. Unless there are any new and more valid objections than "it sucked in 2007" and "we agreed that it sucked in 2007" then I'd be happy with adding the lang parameter back. Chris Cunningham (not at work) - talk 14:40, 19 May 2009 (UTC)

Syntax highlighting is great as a personal preference in one's own editor where you can customize it and turn it off (Lord knows I always use it), but it really doesn't have a place in a general purpose, entry level article. - Richfife (talk) 17:41, 19 May 2009 (UTC)

That's a different debate. The question here is not whether or not the <source> tag should have syntax highlighting, but why we're not using the <source> tag's lang attribute to properly mark up source code when that's what it's provided for. If editors disagree with syntax highlighting then they should be arguing with the MediaWiki developers to turn it off on Wikipedia's deployment, not hacking around it by not marking up code correctly in articles. Chris Cunningham (not at work) - talk 15:20, 20 May 2009 (UTC)

Not really. Mediawiki can decide whether or not to provide it, but the decision to USE it is an article to article (or, more likely, a wiki to wiki one). The software is used on many wikis, so the presence of a particular feature doesn't imply it should be used everywhere possible. - Richfife (talk) 19:03, 20 May 2009 (UTC)

I said "on Wikipedia's deployment". Would you agree that if the Wikipedia instance of MediaWiki has syntax highlighting turned on, that this is an implicit endorsement of the use of this feature on Wikipedia articles? Chris Cunningham (not at work) - talk 01:51, 21 May 2009 (UTC)

No, I wouldn't. Making a particular feature available in the underlying software is not an editorial decision. It's a "here it is. You decide if you want to use it" decision. The maintainers of the media wiki software and the people that decide which features to include in an instance have no more editorial decision making power than you or I. - Richfife (talk) 20:12, 21 May 2009 (UTC)

Update

Seeing as there hasn't been any real pushback on this, I'm going to turn syntax highlighting on again. Most of our high-profile programming language articles use it now, so the inconsistency here doesn't seem to be warranted. Chris Cunningham (not at work) - talk 10:51, 3 July 2009 (UTC)

At the very leasti, I think someone should fix the ridiculous choices of colours first. Yellow on gray background is not really "highlighting", more like hiding. — Miym (talk) 14:11, 3 July 2009 (UTC)

That should be brought up with the MediaWiki developers. I have no idea why people think that using this article as a proxy for getting these things changed is a good idea; all it does it reduce the quality of this article. Chris Cunningham (not at work) - talk 14:23, 3 July 2009 (UTC)

Pushing back. Current consensus, which I agree with, is no. I've never seen a book or online C resource use syntax highlighting and unless there's a defined user by user method in preferences of customizing it or turning it off, it's a bad idea. Also, as I mentioned above, MediaWiki and this article are two separate things. The presence of a feature in the software is not an endorsement of its use any particular article. Until syntax highlighting is added to a programming standard and is not an ad-hoc, after the fact creation, it should be kept out of the articles. - Richfife (talk) 14:54, 3 July 2009 (UTC)

Again, that is using this article as a proxy for a personal disagreement with a development decision. This does nothing to improve the software, but does make this article incongruous with those programming language articles which aren't being watched by editors who disagree with said development decision. Chris Cunningham (not at work) - talk 17:27, 3 July 2009 (UTC)

Development decision != editorial decision. No relation whatsoever. The developers of mediawiki do not dictate the use of features available in articles. Why is that so hard? This was discussed 2 years ago: Talk:C_(programming_language)/Archive_8#Source_language_.3D_C_formatting. Have you tried syntax highlighting with all the Wikipedia skins yet? Have you tried it with all browsers? - Richfife (talk) 19:25, 3 July 2009 (UTC)

Also, the problem with trying to "fix" the software is that there IS no right solution to the problem. Everything is going to look bad somewhere. - Richfife (talk) 19:37, 3 July 2009 (UTC)

C programmers need more care ?

The section on syntax about operator evaluation includes the following sentence: "This permits a high degree of object code optimization by the compiler, but requires C programmers to exert more care to obtain reliable results than is needed for other programming languages." Many other languages don't actually specify an order of evaluation for operands, so I would have thought C's approach was far more reliable. I propose that the sentence be truncated to ""This permits a high degree of object code optimization by the compiler." Any objections ? Cadae (talk) 07:11, 27 June 2009 (UTC)

The sentence quoted is not only referring to "order of evaluation", it is also (and perhaps more significantly) referring to the fact that "The evaluations may even be interleaved." Chris Burrows (talk) 12:43, 27 June 2009 (UTC)

In some other languages the presence or absence of interleaving is not even specified (e.g. Pascal) - again the explicit definition in C (that there could be interleaving) is safer than the situation in some other languages. The problem is that the issues vary by language - C# and Java specify an explicit operand evaluation order so sequencing and lack of interleaving are clearly defined, whereas Pascal, Ada, C, C++ and some others don't specify an order of evaluation for all operands. It is therefore inaccurate to say that C programmers have to exert more care than is needed for other programming languages. Perhaps more care than for Java or C#, but not more care than, for instance, Pascal. Cadae (talk) 10:43, 28 June 2009 (UTC)

c language

why calling c language is middle level language —Preceding unsigned comment added by 59.164.2.104 (talk) 15:24, 10 August 2009 (UTC)

Revised ISO/IEC 9899 Committee Draft

JTC1/SC22/WG14's ISO/IEC 9899 page states "The most current draft of the revised C99 standard is available in N1336." Update to links section required. - 204.111.152.29 (talk) 02:34, 19 October 2009 (UTC)

constant pointers

hi,

my question is about constant pointer

Can you make a constant character pointer point to some other string —Preceding unsigned comment added by 122.167.74.225 (talk) 14:26, 20 October 2009 (UTC)

Not really the place for this, but... It depends on where the const is. The const applies to whatever immediately follows it. You can change "const char *" to point to a different string, but you can't change the contents of the string memory it points to. You can not change what memory "char const *" points to, but you CAN change the contents of the memory. "const char const *" menas you can do neither, but some compilers (*cough*microsoft*cough*) emit a bogus warning on that declaration. - Richfife (talk) 16:36, 20 October 2009 (UTC)

"const char *p" = "char const *p" = non-constant pointer to constant char. However, "char * const p" is something different: a constant pointer to non-constant char. And "const char * const p" is a constant pointer to constant char. (Easier to remember if you read these "backwards": "char * const p" = "p is a const pointer to char".) — Miym (talk) 18:47, 20 October 2009 (UTC)

Generic programming completely absent

The article says:

Only rudimentary support for generic programming

despite being a C programmer that have abandoned C++ for the PODs issues, I must say there is no generic programming whatsoever in C, unless the preprocessor is counted; and since the preprocessor provides no type control whatsoever, counting the preprocessor is not justified. ... said: Rursus (bork²) 10:43, 17 January 2009 (UTC)

It does support a limited form of generic programming with generic pointers; qsort is a good example. Mike92591 (talk) 21:09, 17 January 2009 (UTC)

qsort is not an example of generic programming, rather of first-class functions implemented using function pointers. Adrianwn (talk) 06:44, 6 March 2010 (UTC)

Comma operator links to sequence point?

Under "Operators", there's a group "sequencing" containing only the comma operator, which links to the Sequence Point page. Is this right? While the comma operator is certainly a sequence point, that does not appear to be its primary purpose. From K&R:

Comma operators should be used sparingly. The most suitable uses are for constructs strongly related to each other, as in the for loop in reverse, and in macros where a multistep computation has to be a single expression.

--Mcaruso (talk) 20:44, 24 May 2009 (UTC)

The only functions of the comma operator are to insert a sequence point, and to separate subexpressions for convenience in contexts where multiple things are going on, such as for(p=base,i=0;i<MAX;++p,++i) and if(++p,++i>=MAX). There isn't any name or Wikipedia page for "programming convenience", but there is for "sequence point". — DAGwyn (talk) 02:46, 24 July 2010 (UTC)

Guidance asked for some details about my recent edit

The "minimalism" paragraph talks about the relative ease of implementing compilers that generate efficient machine code, and cites the DEC PDP-11 as a case in point. To expand on the intent of the paragraph I added mention of C compilers for some 8-bit platforms, linking to one that has a Wikipedia page. My two questions are:

1. While the PDP-11's CPU is also 16 bits, the original article seems to stress its 16-bit address space, not the CPU itself; apparently the intent is to stress the compactness of the generated object code as well as access to arbitrary addressable objects. However, the ability to compile efficient object code for simpler CPUs with far less sophisticated instruction sets also testifies to this point. Reading over my edit, though, it seems the juxtaposition of text stressing address space in one case and CPU data size in the other seems possibly confusing. Does anyone have an opinion on this?

2. I am only aware of one such compiler (Aztec_C). My first shot at the sentence said something like, "There is at least one..." That looked awkward, so I changed it to simply "Compliers for..." I can't say with certainty if the plural is actually correct. Does this matter or can the plural wording be considered to be generic and covering both cases?

Rhsimard (talk) 23:21, 19 September 2009 (UTC)

The context was intended to be the compilation environment, not the run-time target, and the initial C implementations were for the PDP-11, which has an address space comparable to the 8-bit platforms that ran Aztec C and ORCA C. Those compilers did not fully implement C89, largely due to size limitations, and fully compliant C99 versions would have to be highly segmented, making them impractical. I have just fixed up the wording to make it clearer. — DAGwyn (talk) 03:01, 24 July 2010 (UTC)

Why C weakly typed?

No matter what source i look at, everything tells me that C is strongly typed. So why not? 81.182.51.168 (talk) 15:07, 14 December 2009 (UTC)

See "casting" - in a strongly typed language, casting is not possible —Preceding unsigned comment added by 192.91.172.42 (talk) 18:34, 14 December 2009 (UTC)

Huh? Yes, it is. The difference is, that a strongly typed language will check the cast for validity at run time or (if possible) at compile time. For example, Java lets you cast a reference of type A to a different type B. If the referenced object does not support type B, an exception will be thrown (or the compiler will report an error). In C, you can cast a pointer-to-int to a pointer-to-float, and no exception will be thrown. Adrianwn (talk) 17:09, 19 December 2009 (UTC)

Yes, casting is possible in even strongly-typed languages, but that's not the issue. "Strongly typed" means that object types are semantically enforced, so that you can't do things like assign a struct pointer to a float variable. The language specifies these typing errors as constraint violations, which is what makes C a "strongly-typed language". Explicit typecasting is way to turn off the built-in strong type checking. — Loadmaster (talk) 19:29, 29 December 2009 (UTC)

I think you're confusing "strongly typed" and "statically typed": those constraint violations that you mentioned are due to the static types of the variables you use. This static type check can be easily circumvented, even without casts. Example:

        int a;
        float b;
        void* p = &a;
        float* q = p;
        b = *q;

This will compile without errors or warnings, making C a weakly typed language — a strongly typed one will either not allow this, or throw an exception at runtime. C can't even be strongly typed, because it has a weak type system and lacks any concept of "objects" and associated type information at runtime. By the way, I found an excellent explanation here: Is C strongly typed?. Adrianwn (talk) 09:28, 30 December 2009 (UTC)

I'll concede the point, but it should be noted that those kinds of conversions are only allowed for conversions to and from void pointer values. Assigning a float value to a pointer, for example, is illegal. — Loadmaster (talk) 19:06, 1 January 2010 (UTC)

websites can also be programmed in C

CGI programming in C never mentioned in the entire article.

1.) Tons of "ink" in the web about which Interpreted language is better for websites... what about C/C++/Java ?

2.) High volume websites use C/C++/Java in critical areas (for speed).

3.) C not only for system and application programming (as Uses section suggests).

Discuss possible new section... and update of "Uses" section ? 83.55.41.191 (talk) 21:38, 4 January 2010 (UTC)

Of course C can be used for any kind of computer programming, including implementing web sites. I don't think it makes any sense to try to list all possible uses. I'd prefer if we just mentioned the most typical uses. — Miym (talk) 21:59, 4 January 2010 (UTC)

I agree with Miym, although to be honest I don't feel all that strongly about it in this case. Any Turing Complete language can be used to do anything (and probably has been). - Richfife (talk) 23:37, 4 January 2010 (UTC)

Stuff removed from Boolean data type article

The following section was removed from the article Boolean data type:

begin removed text
To this day, Boolean values are commonly represented by integers in C programs. The comparison operators (' > ', '==', etc.) are defined to return a signed integer (int) result, either zero (for false) or nonzero (for true). The Boolean operators (&&, ||) and conditional statements (if, while) in C operate on integer values, with the same interpretation. For example, the following C code

int t = (x > y);
if (t) { printf("True!\n");} 
else { printf("False!\n"); }

is equivalent to

int t;
if (x > y) { t = -1; }
else { t = 0; }
if (t != 0) { printf("True!\n"); }
else { printf("False!\n"); }

However, since the C language standards allow the result of a comparison to be any non-zero value, the statement if(t==1){...} is not equivalent to if(t){...} or to if(t!=0){...}.

Since C standards mandate that 0 be interpreted as the null pointer when used in a pointer context or cast to a pointer, one can test whether a pointer is non-null by the statement if(p){...} instead of if(p!=NULL){...} — although some code styles discourage this shorthand. One can also write if(x){...} when x is a floating-point value, to mean if(x!=0){...}.

For convenience, many programmers and C header files use C's typedef facility to define a Boolean type (which may be named Boolean, boolean, bool, etc.). The Boolean type may be just an alias for a numeric type like int or char. In that case, programmers often define also macros for the true and false values. For example,

typedef int bool;
#define FALSE 0
#define TRUE (-1)
...
bool f = FALSE;
...
if (f) { ... }

The defined values of the TRUE and FALSE macros must be adequate for the chosen Boolean type. Note that, on the now common two's complement computer architectures, the signed value -1 is converted to a non-zero value (~0, the bit-wise complement of zero) when cast to an unsigned type, or assigned to an unsigned variable.

Another common choice is to define the Boolean type as an enumerated type (enum) allows naming elements in the language of choice. For example, the following code uses the English names FALSE and TRUE as possible values of the type boolean. In this case, care must be taken so that the false value is represented internally as a zero integer:

typedef enum { FALSE, TRUE } boolean;
...
boolean b = FALSE;
...
if (b) { ... }

Again, since a true result may be any non-zero value, the tests if(t==TRUE){...} and if(t), which are equivalent in other languages, are not equivalent in C.

end removed text

The discussion above is wrong to say the comparison operators return either zero (for false) or nonzero (for true). A true result is not defined as any non-zero value in C - it is defined as 1. Logical expressions are defined to have value 1 if true and value 0 if false. When testing an expression, non-zero is regarded as true, 0 as false. In other words, res = a > b; (where all variables are of type int) is guaranteed to assign either 0 or 1 to res; however, if x contains 27, if (x) will evaluate to true. Also, the use of the word result is being used in a confusing way. - Mickraus (talk) 16:16, 1 February 2010 (UTC)

Is there a place for this text in the C-related articles? Perhaps in the Wikibook? Thanks, and all the best, --Jorge Stolfi (talk) 23:28, 30 December 2009 (UTC)

First program to use Hello, World

According the following wiki page the original "hello, world" was written in BCPL, the grandfather of C. Although it is marked as "citation needed". However this article has no citation for C to be the first program. --Lindy (talk) 09:46, 1 February 2010 (UTC)

This article says something different (which is sourced) Tedickey (talk) 09:52, 1 February 2010 (UTC)

In section: "Hello, world" example, printf is subject to Format String Attack

Original:

printf("hello, world\n");

Modify to:

printf("%s", "hello, world\n");

The "%s" must be included to avoid a Format string attack. Please, discuss... 83.55.41.191 (talk) 21:38, 1 January 2010 (UTC)

After reading that article and a cursory glance at this, I believe the vulnerability is present only when you pass "unfiltered user input" directly to these functions as format strings, as in printf(buffer); where the string buffer gets its value during runtime by user input. In the case of "hello world\n", the simple string "hello world\n" is constant, doesn't contain harmful characters and cannot be altered by user input; so its safe. Instead of "hello world\n" were it the string "%s%s%s%s%s%s%s%s%s%s%s%s", the program would crash (this particular example is from the pdf linked above). --Zvn (talk) 22:36, 1 January 2010 (UTC)

I have not read the linked page but the point is fairly obvious to hard core coders. There is clearly no problem with the current article, and I do not think we need be concerned with providing a full set of best practices, so I do not think any change is needed. Johnuniq (talk) 03:54, 2 January 2010 (UTC)

Agreed. This is not the place for this. - Richfife (talk) 06:01, 2 January 2010 (UTC)

One should also realize the context in which that example was given. It is like showing someone how to drive a car: in a supermarket parking lot, not a lot of care is given for staying on the correct side of the road but merely keeping the hands on the steering wheel. Same here: hello.c is to show how to put things on the screen, not how to be 100% correct. 118.90.14.223 (talk) 09:43, 1 March 2010 (UTC)

Zvn is correct. There is absolutely no problem with the code. Eric119 (talk) 17:30, 2 March 2010 (UTC)

16-bit longs?

Anybody ever heard of a 16-bit long? Specifically, in some old 16-bit version of Visual C++? See Talk:Long integer#16 bits???. —Steve Summit (talk) 13:33, 21 April 2010 (UTC)

As I recall, all versions of Microsoft C/C++ (later called Microsoft Visual C/C++) had 32-bit longs. If there were such a compiler, it would not be ISO-compliant, which requires long int to have at least 32 bits. — Loadmaster (talk) 21:19, 21 April 2010 (UTC)

And the (dubious) claim in question has been deleted. [2] —Steve Summit (talk) 12:37, 24 April 2010 (UTC)

Backwards syntax

Stated as a weakness: "Similarity of the assignment and equality operators (= and ==), making it easy to accidentally substitute one for the other. C's weak type system permits each to be used in the context of the other without a compilation error (although some compilers produce warnings). For example, the conditional expression in if (a=b) is only true if a is not zero after the assignment"

One text I read suggested a way to avoid this error: Keep a constant to the left of a variable. Whereas "if (3 == userChoice)" is just as good as "if (userChoice == 3)" for a comparison, using "if (3 = userChoice)" will always result in an assignment error. It's brilliantly simple . . . but I could never develop the habit of writing those expressions "backwards"! WHPratt (talk) 19:00, 29 December 2009 (UTC)

Yes. While it's somewhat common in some circles to see expressions such as NULL == p, I personally find it hard to read, having a backwards literal reading to normal English logic ("Null is equal to pointer p" instead of "Pointer p is null"). Perhaps the article should have a sentence or two about this programming idiom. — Loadmaster (talk) 19:23, 29 December 2009 (UTC)

The article should not attempt to cover programming style, or it would grow way too large. Also, such matters are disputable; for example, I agree that it is harder to read the "safer" form described by WHPratt above. Frankly, I know of no experienced C programmer who makes the cited mistake, so it's totally unnecessary to contort the natural form of expression. — DAGwyn (talk) 02:38, 13 May 2010 (UTC)

OOP with ANSI-C

"ANSI-C is a full-scale object-oriented language" Object-Oriented Programming With ANSI-C by AT Schreiner - 1993

It would be nice to have a section on OOP techniques. —Preceding unsigned comment added by 128.138.64.222 (talk) 01:03, 19 February 2010 (UTC)

C can be used to create object oriented programs. I've had to do it several times (For the Dreamcast and some embedded systems), but only in cases where no C++ compiler is available. In fact, most early C++ implementations were in the form of a preprocessor to generate straight C code. But it's not what it's for. Nowadays, the circumstances where a C compiler is available but a C++ compiler is not are very few and far between. That was not the case in 1993 (when the article was written), but it is the case now. This article is supposed to be an overview, not a complete be-all and end-all. - Richfife (talk) 01:17, 19 February 2010 (UTC)

Schreiner is simply wrong—so-called "ANSI-C" is not appreciably "object-oriented" in the sense in which that term is currently used by software engineers. In fact, his book illustrates that there is a lot of work needed when using C to simulate an object-oriented language. — DAGwyn (talk) 02:54, 13 May 2010 (UTC)

Just wondering...

Why do people prefer lang="text" instead of lang="c"? ThePCKid (talk) 23:54, 8 May 2010 (UTC)

Some people don't like the particular highlighting scheme MediaWiki uses for C. I don't agree, but anyway... --Cybercobra (talk) 00:31, 9 May 2010 (UTC)

I like the highlighting... ~ThePCKid (talk) 03:43, 9 May 2010 (UTC)

Well, you can try and apply WP:BRD and see if the consensus has changed / will change. --Cybercobra (talk) 04:17, 9 May 2010 (UTC)

Discussion higher up on the page - Richfife (talk) 06:22, 9 May 2010 (UTC)

A meta-answer is that syntax highlighting is not part of the programming language; it's at best a crutch and at worst a nuisance. — DAGwyn (talk) 02:57, 13 May 2010 (UTC)

But it's an extremely useful and widely used crutch. --Cybercobra (talk) 08:50, 13 May 2010 (UTC)

My 2¢ worth: Minimalism (KISS): Keywords should be bold and/or colored, comments should be italic, and everything else should be normal text. For example:

int main(int argc, char **argv)
{
    printf("Hello, world!\n");  // Print a message
    return 0;                   // Exit cleanly
}

It seems this has been discussed at length in the past, but I'm throwing my agreement in with the current consensus, to omit syntax highlighting and use plain text, primarily for the first reason DAGwyn cites. However, I would probably support highlighting on implementation examples outside of articles about specific languages (e.g. if there were a C implementation of quicksort on the quicksort article, I'd support using lang="c"). /ninly_(talk) 22:51, 2 June 2010 (UTC)

Array-pointer interchangeability

Should the main article mention that the types of the following 3 expressions are different?

  &arr[0]
  arr
  &arr

As a consequence of the recursive application of the derived type/element type relation described in 6.2.5 Types, par. 20 of WG14 N1124, &arr[1] and &arr + 1 will point to different areas if arr has more than 1 element. --ilgiz (talk) 17:04, 2 April 2009 (UTC)

I don't think the article should try to explore such details; it's not a programming tutorial. — DAGwyn (talk) 18:12, 6 May 2009 (UTC)

About this phrase->

"Despite this apparent equivalence between array and pointer variables, there is still a distinction to be made between them. Even though the name of an array is, in most expression contexts, converted into a pointer (to its first element), this pointer does not itself occupy any storage, unlike a pointer variable. Consequently, what an array "points to" cannot be changed," [...]"

IMHO, I think that text in bold is not a good indication of distinction between array and pointer, because the same restriction applies to const pointers (these also we can`t change what they points to), as in:

int *const MyPointer;

So in my opinion, text in bold should be deleted from article. Also, can it be that array variable REALLY is just read-only pointer ? (as in my given example). —Preceding unsigned comment added by 84.32.222.96 (talk) 20:38, 12 November 2009 (UTC)

No storage for the array address means compile time calculation of its offsets. The const modifier of the pointer may be circumvented at run time by casting. Modifying array offsets at run time would require interfering with the generated code and temporary storage. --ilgiz (talk) 21:33, 12 November 2009 (UTC)
- Thanks, for explanation about pointer const modifier circumvention. Now i am totally confused. Whats the point of having const modifier if we can bypass it by just casting ? Huh. IMHO, this may be design flaw in C. This may mean that:

1. C don`t needs const modifier for pointers at all. OR

2. C should be changed such that const modifier may not be bypassed by simply casting const pointer to non-const pointer before address assigment.

It`s a pitty that such flaw exists. —Preceding unsigned comment added by 84.32.222.96 (talk) 09:37, 13 November 2009 (UTC)

Number (2) is already in place. I believe a warning may be emitted by a C compiler when const-ness is cast away. The point in allowing a bypass is to work around the older code unaware of const modifiers when it interleaves with the new code. The proper fix would involve massive changes to the older code. --ilgiz (talk) 16:48, 13 November 2009 (UTC)

The const keyword is meant to be part of the contract between the function provider and the client. As such, it is designed to inform the client that there is a promise that a variable or parameter will not be modified by the function. However, since the variable may actually be provided by the function writer (especially if it is an opaque structure), it is reasonable to allow it to modify the variable as part of its internal operation. Thus the possibility of "casting const-ness away" provided by the language. C was designed with the principle that the programmer knows what he is doing, and therefore it should provide features to allow him to do useful things instead of hindering him. By the same token, the programmer must explicitly override the default behavior in order to do this. — Loadmaster (talk) 00:07, 14 November 2009 (UTC)

You can apply (and remove) const qualification to a type via casts, as well as declaring objects to have that qualification intrinsically. A static object with intrinsic constness can be allocated in unwritable storage (ROM), and many compilers do that. If you try to cast away intrinsic constness, you get undefined behavior. — DAGwyn (talk) 02:35, 24 July 2010 (UTC)

The build process

may i know about the problems in the data added by me on build process.....? —Preceding unsigned comment added by Aravindvijayanpala (talk • contribs) 12:59, 6 June 2010 (UTC)

It's not topical. This is about the language, not about a particular way of using it. For instance, there have been C interpreters, which do not fit into your outline. Tedickey (talk) 13:32, 6 June 2010 (UTC)

C's suitability for numeric and scientific computing

Regarding the following paragraph:

C is efficient for numeric and scientific computing, due to its low overhead, low-level nature of the language, compiled nature of the language, and availability of a decent math section in the C standard library. Examples of C usage in numeric and scientific computing include GMP, GNU Scientific Library, Mathematica, MATLAB, and SAS.

The Citation needed-tag keeps on getting removed, altough no sources for those claims (in the first sentence) are given. Examples of programs written in C do not back these claims up; and in any case, this would constitute original research. For the record, I don't think that C is very well suited for numeric and scientific computing, because it lacks a lot of important data structures, and the math section of its standard library is rather mediocre.

Before I reinsert the tag, I would welcome a discussion. – Adrianwn (talk) 06:09, 6 July 2010 (UTC)

I have not noticed this disagreement, so I am simply responding to what you have written above. What would you want a citation for: C has a low overhead? low-level nature? compiled nature? decent math...library? C used for GMP, GNU Scientific Library etc? Aren't these all rather obviously true statements? Or is your claim that it is synthesis to arrange this material in this way? Johnuniq (talk) 07:12, 6 July 2010 (UTC)

I will try to be more precise:

"low overhead, low-level nature of the language, compiled nature of the language" – these are pretty obvious, and probably mentioned somewhere in the article
"availability of a decent math section in the C standard library" – this is not true; actually, the math section is rather sparse (see here). The standard library does not provide vectors, matrices, graphs, arbitrary precision, fast multiplication, etc.
I don't ask for a citation for the examples (note that the fact-tag refered to the first sentence)
The implication ([low-level, low overhead, compiled] --> efficient/well suited for numeric computation) itself probably needs a citation, since the premisse is not sufficient for the conclusion

My problem is that the paragraph implies that C allows to efficiently write efficient programs for numeric and scientific problems, which is absolutely not the case: you can write efficient programs in C, but it is a lot of work. Besides, you can write all kinds of efficient programs in C, in the same way that you can write efficient programs in assembly, but neither assembly nor C are particularly well-suited nor intended for numeric computation.

Come to think of it, it might be best to rewrite the paragraph and give it a new direction. – Adrianwn (talk) 11:09, 6 July 2010 (UTC)

I agree. You can do anything in any Turing Complete language, that doesn't mean you should. People do write this sort of program in C, but I think they do it for reasons that don't have anything to do with the language. More because of compiler availability and maturity, anticipation of it being maintained by other people that may not know a particular lower profile language, the writer themselves not knowing any other language, etc. The paragraph should probably focus more on that fact that C IS used this way than whether it's a good choice. The strictness of C syntax will always add a cognitive load to the process of translating a formula to and from C code. Also, the fact that the math happens in libraries adds function call overhead, although modern optimizations sometimes reduce this. - Richfife (talk) 20:53, 6 July 2010 (UTC)

Since there were no more objections, I went ahead and changed the paragraph. It better reflects the advantages of C regarding efficiency now; however, the tone and style are not optimal yet, and a citation to back it up wouldn't hurt either. – Adrianwn (talk) 12:36, 14 July 2010 (UTC)

It's more accurate now. Good work. --Frederico1234 (talk) 14:07, 14 July 2010 (UTC)

Perhaps. Although I'd like to point out that my colleagues who were doing fluid dynamic simulations were primarily working in C. I knew one or two who were working in "off-the-shelf" softwares built for the purpose, but that was because they didn't know how to program in C. But I digress. On an unrelated note, I refrained from adding to the article that C IS THE ONE TRUE PROGRAMMING LANGUAGE because I felt it would be difficult to source something like this, no matter how obvious. —Preceding unsigned comment added by 66.87.5.116 (talk) 00:03, 7 November 2010 (UTC)

Although, since it's an encyclopedia, I would add that the disadvantage of C is that the lack of compiler-managed by-ref variables made it difficult to write efficent code in C. Features of C99 like the strict-aliasing rules and the Restrict keyword aim to make C as efficient as FORTRAN and Pascal were for scientific and numeric applications: however, the implementation breaks some programs, and is still not correct or complete in some compilers.

"The effect can be measured by comparing a program that uses pointers ... with a similar Fortran program ... This was the motivation for a standard solution."

-- From Rationale for International Standard - Programming Languages - C [std.dkuug.dk] (6.7.3.1 Formal definition of restrict)

203.206.162.148 (talk) 08:24, 23 September 2010 (UTC)

Then why don't you add that? Be bold :-) – Adrian Willenbücher (talk) 09:33, 23 September 2010 (UTC)

"Hello world" example using puts() instead?

I think it makes more sense to use the puts function instead of printf, as the "\n" is not necessary. I have seen printf used in every example I can remember, however. Edit it if you think it's a good idea though. 'FL a RN'(talk) 03:25, 28 July 2010 (UTC)

"Hello World" isn't intended as an optimized demonstration of the most efficient way of printing that string to the screen. It's just a standard way of showing a minimal program in a given language using the most common calls. A lot (and I mean A LOT) of people have dinked with the code. The way it is is the standard way that it's shown in all the C standard books. Leave it be. - Richfife (talk) 05:22, 28 July 2010 (UTC)

Syntax highlighting in the examples

There was some discussions in the past (Talk:C_(programming_language)/Archive_9) about whether to have syntax highlighting in the examples. However, no arguments except 'these colors are ugly' were presented. So, unless anyone points to another high importance C/C++ article without syntax highlighting, I will put the syntax highlighting back to the article.1exec1 (talk) 22:01, 12 October 2010 (UTC)

The beauty or lack of same of the colors is not the point. The point is that a C program is a sequence of characters, and the character set used does not include differently-colored characters. Presenting examples of the programming language with colors that are not a part of the language definition would be grossly misleading; the language definition does not attach meanings to colors, and therefore a program is the same no matter which colors one chooses to display each character with. We should not pretend to our readers that the language is something it isn't. –Henning Makholm (talk) 22:29, 12 October 2010 (UTC)

(edit conflict)That is completely ridiculous. Almost every other programming lang article for which highlighting is supported utilizes it. Next to no one thinks syntax highlighting is somehow part of language definitions. And in practice, programmers almost always use editors that do syntax highlighting. Whether the coloring is ugly and whether that ugliness should be considered WRT using highlighting, are other issues entirely however. --Cybercobra (talk) 23:31, 12 October 2010 (UTC)

Well, any programming language is 'a sequence of characters'. The same argument can be applied to almost every digital object, we could read Wikipedia in its source form, but why should the regular reader? Would wikipedia be among the most visited webpages on the internet? I guess no. Seeing such a response after such a minor change I think I won't argue anymore. Maybe it's better that our readers chose C++ instead of C. It has examples that look better after all. 1exec1 (talk) 00:45, 13 October 2010 (UTC)

@1exec1: It is often better to go along with the consensus, particularly for trivia like this. Please leave the article in its established state (which I strongly support). Johnuniq (talk) 23:27, 12 October 2010 (UTC)

"Consensus" is such a useful word! Simply mentioning it is sufficient to convince everyone that things should stay as they are. This even works when no real consensus exists, as can be seen by the regularly occuring discussions (remember that Wikipedia decisions are not made by popular vote). If anything, WP-wide there is a consensus that syntax highlighting should in fact be used, as can be seen in every article about a programming language for which syntax highlighting is available.

Since those discussions didn't lead to a consensus in the past, and since no one seems to be able to have the colors defined by the MediaWiki software changed, I propose another solution:

long int SomeFunction();
/* int */ OtherFunction();

/* int */ CallingFunction()
{
    long int test1;
    register /* int */ test2;

    test1 = SomeFunction();
    if (test1 > 0)
          test2 = 0;
    else
          test2 = OtherFunction();

    return test2;
}

Since C is mostly a subset of C++, using C++ syntax highlighting works just fine, and it seems good enough for the C++ article. Opinions?

On a related note: why was some_function () changed to SomeFunction ()? This is rather unusual for C, so I suggest it should be changed back. – Adrian Willenbücher (talk) 06:33, 13 October 2010 (UTC)

The C++ highlighting has exactly the same problem as the C one has: It pretends that the program contains features that are simply not part of the character string that the language assigns a meaning to. The language is the object under discussion; the article should not pretend that the language does something that it actually doesn't. That would be dishonest. –Henning Makholm (talk) 10:25, 13 October 2010 (UTC)

That's a pretty weak argument for the following reasons:

1) Highlighting the syntax doesn't pretend anything. After all, you could say the same about indentation (indentation is not part of the language definition), so the example should look like this in order to be not "dishonest":

long int SomeFunction();
/* int */ OtherFunction();

/* int */ CallingFunction()
{
long int test1;
register /* int */ test2;

test1 = SomeFunction();
if (test1 > 0)
test2 = 0;
else
test2 = OtherFunction();

return test2;
}

Actually, those line breaks don't have any meaning for the program either, so they should be removed as well, together with redundant whitespace:

long int SomeFunction();/* int */OtherFunction();/* int */CallingFunction(){long int test1;register /* int */ test2;test1 = SomeFunction();if (test1 > 0)test2 = 0;elsetest2 = OtherFunction();return test2;}

There, now we have removed everything which doesn't influence the semantics of the program. What a clear, informative example!

2) As was mentioned before, just about every other programming language article uses syntax highlighting. Are you saying that those should be changed, too? If not, why is C different? – Adrian Willenbücher (talk) 14:16, 13 October 2010 (UTC)

(1) Whitespace is certainly part of the input stream to the language implementation that the language standard explains how to interpret. The fact that the language definition explicitly says that whitespace is ignored (except when it isn't, such as in string/character constants, or between identifiers/keywords) underscores this. In contrast, language definitions do not need to specify that the compiler ignores the color of characters, exactly because from the language's point of view, characters do not have any colors to ignore in the first place.

(2) Correct. Articles about programming languages that are defined without a notion of character colors should not use colored characters in their examples. –Henning Makholm (talk) 17:50, 16 October 2010 (UTC)

So then since the language definition ignores whitespace, how do we choose what whitespace to use? By adopting whatever the convention is in that language's community, hence why we don't have everything on 1 line. I submit that using syntax highlighting is likewise conventional, and that C programmers not using highlighting fall into a distinct minority. --Cybercobra (talk) 18:19, 16 October 2010 (UTC)

The language definition doesn't ignore whitespace. It explicitly describes whitespace as being part of the input to the compiler. The examples in the article are examples of input to the compiler; therefore whitespace is apropriate in the examples. However, the input to the compiler is not colored; therefore color is not something that is appropriate to include in the examples. –Henning Makholm (talk) 18:43, 16 October 2010 (UTC)

Regardless of what we term the compiler's treatment of whitespace, how do you explain the choice to include the specific whitespace that the current article does? Also, fonts aren't input into the compiler either, so by your logic we don't need to make the code in monospaced either. --Cybercobra (talk) 19:12, 16 October 2010 (UTC)

The examples in the article (and the article itself, actually) are not intended for language lawyers. Using C's specification as an argument completely misses the point: the colors are intended to clarify different parts of the code for readers new to the language. They won't look at them and think "Gee, I wonder whether those colors have a defined semantic in C's specification. Also, I better look up how my compiler's parser has to handle whitespace." Now I can understand that there is resistance against using the MediaWiki C colors, but saying that there should not be any syntax highlighting really goes against accepted consensus. – Adrian Willenbücher (talk) 23:45, 16 October 2010 (UTC)

I'm recusing myself from this topic. As a personal policy, I never participate in a debate for more than a year. - Richfife (talk) 18:02, 13 October 2010 (UTC)

+1 on using syntax highlighting like every other popular programming language article. --Cybercobra (talk) 18:13, 16 October 2010 (UTC)

+1 here as well. The argument "the C compiler doesn't understand colors so we shouldn't show colors" is ludicrous, akin to saying that chemistry articles shouldn't show molecular structure diagrams because that's not what atoms really look like. Bravo Cybercobra for bold execution. —chaos5023 (talk) 21:37, 29 October 2010 (UTC)

No typeface in existence (or font as some people call it) that can be used to display text on Wikipedia is a part of the language definition, which doesn't define the forms of the character set used in C source code at all. No characters - not to mention colours - should, therefore, be visible in any of the code examples.213.138.152.225 (talk) 09:29, 26 October 2010 (UTC)

I haven't looked in the archives, but what's lacking from both sides of this discussion here are references to how reliable sources on the topic present the material. There is no color encoding in K&R, for example. Unless more recent sources use colors, I'd say stick with no color, per sources. --Born2cycle (talk) 21:37, 4 November 2010 (UTC)

That would be an overapplication of WP:V so enormous as to amount to a reduction to absurdity. No consensus exists on Wikipedia for that slavish an adherence to sources. —chaos5023 (talk) 21:48, 4 November 2010 (UTC)

Or to put it in other terms, syntax highlighting is a formatting and presentation issue, not an informational issue; formatting and presentation have always been matters of editorial judgment, and I really don't see that changing. —chaos5023 (talk) 22:00, 4 November 2010 (UTC)

Well, I'm not suggesting we are required to follow sources for this issue, but it's worth considering, especially since there appears to be no consensus on this issue. And I say that without knowing what the latest books on C (are there any?) are doing. But why not follow the editorial judgment of reliable sources? After all, if it is deemed to effectively convey the information in texts designed to convey the information, why should we do something different? --Born2cycle (talk) 23:46, 4 November 2010 (UTC)

Few programming books are printed in color; we have no way of knowing whether they'd colorize it if they were to print in color. --Cybercobra (talk) 00:05, 5 November 2010 (UTC)

I went through the A, B and C sections of List_of_programming_languages, and counted articles with syntax highlighting. Of the 149 items in the A/B/C lists, 73 included code samples of some sort, of which 43 (59%) had some form of syntax highlighting (colors, bolding, fonts, underlines). If we eliminated short articles or articles with very short code samples (in a few cases there was only a *single* line of unhighlighted sample code), the percentage would be higher. While there are certainly longer articles and longer samples without syntax highlighting (Cobol, for example), there is a definite additional bias towards having syntax highlighting in those cases. I don't believe that any of those languages use that highlighting in a syntactically or semantically meaningful way, and it exists only to provide clarity to the reader. Also, several languages clearly related to C (B, C++, C#, for example), also use syntax highlighting in their examples. So I think there's definitely something approximating a consensus that syntax highlighting in the code samples in the articles on programming languages is generally a good thing. Rwessel (talk) 06:08, 5 November 2010 (UTC)

You have to take into account that not every language has syntax highlighting support by the Wikimedia software. Counting only those articles probably results in an even higher ratio. – Adrian Willenbücher (talk) 08:15, 5 November 2010 (UTC)

I think it's a bad idea to have the syntax highlighting. Where is the evidence that it provides clarity to the user? It's just as likely that the reader is confused by the colors. The syntax highlighting could easily lead to the false impression that the colors are part of the language. The colors distract from the true nature of the language, and try to substitute a silly gimmick for good coding practice. Syntax highlighting is certainly not part of the spirit of the language, since few or none of the books use syntax highlighting. If syntax highlighting really added clarity, the books would use it, even if not in color. The books already use different fonts in other contexts, but rarely if ever for source code. I've read just about every C book there is, and never seen syntax highlighting. The way to make C (or just about any) code understandable is by the formatting. That way it's easy to read in just about any format, just about anywhere. And even if other wikipedia programming language articles use syntax highlighting, "two wrongs don't make a right". My guess is that most of those in favor of syntax highlighting don't understand how to write good C (or other) code. They've never put in the serious study and time needed. They try to fall back on some silly gimmick like syntax highlighting. This appears to be just more of the "dumbing down of the American programmer" (I happen to live in US). 174.31.130.32 (talk) 04:57, 23 November 2010 (UTC)

First, calling other people stupid is rarely productive. Even if you are better than the rest of us, pointing it out is likely to cause more resentment than anything else.

There certainly have been books with syntax highlighting, although I'm not personally aware of any C examples (going by the contents of my bookshelf*, it seems to be particularly popular in Pascal books, for some reason). The options available to books are more limited (no color, in most cases), and generally more intrusive (bolding, underlining), and so is a of less value than using colors

While you're correct that doing something just because everyone else is does not make it right, it's not just Wikipedia - many online programming language tutorials/documents/references use syntax highlighting.

Syntax highlighting is certainly a part of almost all programming editor, and while it can almost always be turned off (usually without too much effort), it's rare that it is, hence the programmers seem to find some value in it.

And exactly which formatting style should we use? I'm sure we could start quick start another flamewar or two by declaring The One True Brace Placement Style, and the correct number of spaces tabs should indent. From the language's perspective, almost all of that is subjective, and "fluff."

*it also raises the interesting question of why I have more Pascal references on my book shelf than C references, given that I probably haven't written a thousand lines of code in the former in the last 30 years... Or maybe that *is* the reason... Rwessel (talk) 19:16, 23 November 2010 (UTC)

1) I didn't call anyone stupid. I said most "have not put in the serious time and effort needed". That's just reality. It's not easy writing good code. And there is no "short cut". I'm not smarter. It took me more than a year to learn ANYTHING. I've just worked harder and been willing to fill in my knowledge gaps. 2) Maybe you don't know what "dumbing down" means. It's a phenomenon that many others have discussed, not something I made up. 3) In answer to your question "exactly what formatting style", I would suggest you read "Code Complete" several times (which, BTW, does not use syntax highlighting. There are several accepted and widely used styles, any of which is fine. You are right there is no cause for a flame war. And of course good formatting is just one part of writing good code. But syntax highlighting has basically nothing to do with writing good code. 4) If someone wants to use syntax highlighting in their programming editor, that's fine with me. If they want to waste time fiddling with the arrangement of the pencils on their desk, that's OK with me too. But personally, I find it makes not a bit of difference. As far as I can tell, syntax highlighting makes it neither easier (nor more difficult) to write and maintain code. Syntax highlighting seems totally beside the point. To me it just seems a cosmetic gimmick that might distract from the real effort needed to write good code. And in the article (back to the MAIN POINT), it could easily gives a false and misleading impression that the colors might be a part of the language. 5) If books wanted to use the supposedly so helpful syntax highlighting in black and white, they certainly could. Bold. Underline. Italic. Bold underline. Bold italic. Different font family. Italic underline. Etc. I'm sure we could come up with at least 6 to 10 good black and white options. I think the reason it's not normally used is because it's not really helpful, just kind of distracting. 5) I have nothing against pascal. It's a fine language. But that's funny the pascal books used syntax highlighting, and the C books didn't. I think you really found something interesting there! Maybe the pascal article should have syntax highlighting, and not the C article. 97.126.54.135 (talk) 07:51, 29 December 2010 (UTC)

OK, it's clear that *you* don't find syntax highlighting of value, I don't think that was ever in much doubt. The point is that many people seem to find value in it, or it would be used in fewer online tutorials, and the people writing editors would not have gone to that considerable trouble, and the users of those editors would turn the feature off.

FWIW, in the survey I did back in November, the one language article I specifically cited as having more-than-trivial sample code and no syntax highlighting (Cobol), now has it. (I have not repeated the survey, but I happened to notice that change). Rwessel (talk) 08:39, 29 December 2010 (UTC)

I hate to say it...

But I'm starting to wish you could semi-protect an article only from IP addresses in a particular country. Check the history if you don't know what I mean. - Richfife (talk) 20:12, 29 October 2010 (UTC)

Things don't work like that on the internet.109.240.89.13 (talk) 20:52, 31 October 2010 (UTC)

Actually, it often does. Regional IP blocking is quite common. I was not making a serious suggestion, though. Just expressing frustration. - Richfife (talk) 23:33, 31 October 2010 (UTC)

Nah, we just need to stop allowing anonymous IP's to edit the encyclopedia...

Sebastian Garth (talk) 15:23, 4 November 2010 (UTC)

Yes. And we should only allow experts to post. And they should be peer reviewed. Why hasn't that been tried? Oh, it has. - Richfife (talk) 16:53, 4 November 2010 (UTC)

I just meant that most people who should be banned from any given website probably also know their way around such bans.109.240.208.115 (talk) 22:56, 2 November 2010 (UTC)

So you want to ban entire country because several editors are vandalizing pages. I doubt this is a good idea 1exec1 (talk) 20:14, 3 November 2010 (UTC)

As I said, "I was not making a serious suggestion, though. Just expressing frustration." - Richfife (talk) 21:56, 3 November 2010 (UTC)

POVvy style

Some small fixups needed: C is not one of the most popular programming languages of all time, it is one of the most used languages of all time (I use it extensively but many aspects of it are really annoying); it is used for producing "fairly portable" programs, not just "portable"; there are also other signals that indicate fan club edits:

A standards-compliant and portably written C program can be compiled for a very wide variety of computer platforms and operating systems with little or no change to its source code.

is not well balanced, a port usually needs some port recoding because of the unstandardized signed/unsigned and wchar_t policies of different compilers, and no change only for rare trivial code. Rursus dixit. (^mbork³!) 10:29, 18 December 2010 (UTC)

Thing is, the sources cited purport to measure "popularity", not amount of use (whatever that means in this context). To phrase otherwise would be to misconstrue the sources. Portability issue addressed. --Cybercobra (talk) 00:34, 19 December 2010 (UTC)

The distinction between "popular" and "used" is lost on me. If some aspects are "annoying", that seems a different issue. 97.126.54.135 (talk) —Preceding undated comment added 07:56, 29 December 2010 (UTC).

I think it is fair to say that C is well suited for writing portable programs. Yes, some changes are usually needed to the source code. Obviously UNIX does not have drive letters, Windows does. There is the matter of '/' vs '\'. And there are surely other differences that need to be taken into account. Some other languages are also rather portable, but in a different kind of way. Java can run in any JVM (and use JIT), Javascript can run in any browser, perl can run in any perl interpreter. There are surely other examples of portable languages. However, a difference seems to be that the low-level nature of the C language and close relationship to assembly language makes it easier to write a C compiler for any cpu, and then C is portable as a machine-language executable to that architecture. Also, I would say the C preprocessor makes it much easier to write portable programs. 97.126.54.135 (talk) 08:31, 29 December 2010 (UTC)

If you have porting problems with signed/unsigned or wchar_t, you're not using them correctly. I can see that that would annoy you, but it's not inherent in C. — DAGwyn (talk) 12:49, 23 January 2011 (UTC)

I feel like using "popular" would be more biased because popularity isn't exactly measured by a quantitative factor, whereas "used" is provable in statistical data 71.75.97.45 (talk) 01:32, 4 February 2011 (UTC)

Related ... kind of ... not ...

Section Related languages shoots itself in the foot regarding Python:

has a different sort of C heritage. While the syntax and semantics of Python are radically different from C, the most widely used Python implementation, CPython, is an open source C program. This allows C users to extend Python with C, or embed Python into C programs ...

which is nonsense. The text claims that it has a heritage, then no heritage at all (confusing "implemented in" with "inheriting from"), then alleging a diversity of connections that has nothing to do with "heritage" as proof of heritage.

The fact is that Python has no heritage from C at all. ~~I propose removing it.~~ Rursus dixit. (^mbork³!) 15:10, 14 June 2011 (UTC)

No, I propose rewriting it, making a subsection of C-implemented languages. They don't inherit, they peruse. Rursus dixit. (^mbork³!) 15:23, 14 June 2011 (UTC)

As Python has been removed from the related languages section, should it also be pulled from the "influenced" section of the infobox (and the back link from the Python infobox)? Rwessel (talk) 01:15, 15 June 2011 (UTC)

"Standard conforming"? What standard

To what lengths are we going to implement "standard"s? Somewhere in comments about various entries in the Underhanded C Contest (website http://underhanded.xcott.com/) there is the point that the "printf" of "hello, world" should be:

   printf("%s", "hello, world\n")
or 
   printf("%s\n", "hello, world")

Old_Wombat (talk) 11:37, 25 April 2011 (UTC)

Gonna need a more specific citation than an entire website. --Cybercobra (talk) 14:05, 25 April 2011 (UTC)

That claim is made occasionally, it's not correct. It *is* a very bad idea to pass in an unknown format string to printf(). Thus ps="hello, world"; ... printf(ps); is risky if you don't know for sure that ps points to a valid format string. And if the string to be printed contains any escapes("%") that printf will try to interpret, it requires special care to pass as the first parameter. But obviously neither of those apply in this case. Rwessel (talk) 15:57, 25 April 2011 (UTC)

Let's just use "Hello World" as it first appeared and go about our day. I'm sure we can all write hundreds of valid variants ("Let's find a Taylor Series that generates those ASCII codes!", "I can do it in 27 characters!", etc.) and arguing over which one is the best is no more likely to get anywhere than arguing over bracket placement or byte-ordering. - Richfife (talk) 17:35, 25 April 2011 (UTC)

It's funny just how often "Hello World" debates crop up, isn't it? Sort of like debating about which direction to put the shirt on the hanger—should we *really* spend so much time arguing about such trivial things? Jeez. Sebastian Garth (talk) 03:07, 26 April 2011 (UTC)

I'm a toilet-paper-rolls-to-the-front kind of person myself. The string "Hello, world\n" is not an unknown format string; the programmer can see every character in it in the call to printf(). Let's just leave the original Hello, world example the way it is in the original white book, shall we? — Loadmaster (talk) 02:42, 13 August 2011 (UTC)

Strong typing vs. weak typing

In the Wikipedia article on strong typing, C is classified as a strongly typed language, and the examples there seem to illustrate that; so why in the infobox to this article is C tagged as a weakly typed language? —Avstin (talk) 05:12, 7 October 2011 (UTC)

This has been discussed several times, you may want to search the talk page archives. Strong vs. weak typing is not that consistently defined, variously meaning the inability to mix variables of different types or relating to the degree of type safety. Nor is it a binary attribute. C is more type safe than some languages, and less so than others. And frankly Strong typing is a pretty poor article. The example there really shows strong vs. weak typing in only one of the common uses - it describes it in terms of allowing combinations of different types of values to be used in an expression, but the while the examples shown are weakly typed in that sense, they are not unsafe in the sense that you can really muck things up if you convert pointers poorly, or pass incorrect types to printf(). The description in Type safety is important too. Depending on your preferences, it would be fair to describe C as moderately strongly typed, or moderately weakly typed. There's definitely some cleanup needed, but I think the main problem is at Strong typing. Rwessel (talk) 06:16, 7 October 2011 (UTC)

An even more pedantic point

There is NO SUCH THING as a "curly brace" or for that matter "square bracket". There are:

parentheses: ( )

brackets: [ ]

braces: { }

Old_Wombat (talk) 11:43, 25 April 2011 (UTC)

Basis for your claim? --Cybercobra (talk) 14:07, 25 April 2011 (UTC)

Here's "a" basis for such a claim: The C Programming Language (Brian W. Kernighan, Dennis M. Ritchie, Prentice-Hall, 1978). In the description of the first "hello, world" program, (p4) "The braces { } enclose the statements that make up the function; ..." First mention of "bracket" in connection with use in a C program. Not "first ever", but likely the first in book form. Also, in the REAL standard prior to 1998, C A Reference Manual (Samuel P. Harbison, Guy L. Steele, Prentice-Hall, 1984) Section 7.3.4(p.146) begins, "A subscripting expression consists of a primary expression, a left bracket, an arbitrary expression, and a right bracket."

Also, in the standards: Nowhere in the C99 (draft as of 1998) or C++ 1998 ISO 14882 standards does the word "curly" occur in any context, much less as "curly brace". Braces is braces. The term "square bracket" occurs once only in the C99 draft, in the context previously mentioned (below) at 6.5.2.1. I don't have a copy of C98 to look at, but it's curious that the corresponding paragraph in C++1998 reads the same...but that makes a bit of sense because < > are used as "angle brackets" in C++. Nowhere else in either document does "square bracket" occur.

As for the Unicode Database, "left/right bracket", and "left/right brace" are also listed names for { } [ ] respectively. I don't know about modern standards, but the mathematical use in secondary school in the 1960s and college in the 1970s was "parenthesis", "bracket" and "brace"; in order of preference as a grouping symbol. Math usage in those days influenced more computer language than did typography, which is the basis for the Unicode Character Database. We're discussing C, which has "functions", not "procedures", after all. — Husoski (talk) 00:44, 12 July 2011 (UTC)

You're arguing for the common (programmer's) informal names of the characters, and against the international standard names for them. In a source like Wikipedia, it's more appropriate to use the standard nomenclature. The informal names can be mentioned, but they obviously don't carry the same authoritative weight that the official terminology does. — Loadmaster (talk) 19:28, 13 July 2011 (UTC)

No, I am not. In fact, I supported the original assertion with references for the names of these symbols as used in C. The Wikipedia entry on poker describes certain card holdings as "straights" or "straight flushes", even though the same group of cards in other card games is called a "run" or "run in suit".

I am arguing for using C sources for C terminology. I do not consider the Unicode Character Database as a definition of symbol names as used in C. The UCD has no authority regarding the naming of symbols as used in C. For example, the primary UCD name for the \ character is "REVERSE SOLIDUS". (Yes, these are all caps in the UCD.) However, in C it is a backslash. If the UCD were to disagree, it would be the UCD that were in error--just as it would be if a Wikipedia entry said the same thing. The correct approach, IMHO, is to mention other names for the symbols as used in other contexts--if that's required at all--rather than to obscure the C usage in an article about C. "Square bracket" has some justification, just barely, in the C literature. "Curly brace", on the other hand, does not appear to have serious support. UCD notwithstanding. — Husoski (talk) 22:49, 13 July 2011 (UTC)

Bracket points out that all three terms are ambiguous depending on the speaker (for example, British common usage of "bracket" is equivalent to US parenthesis), and lists "square bracket" and "curly brace" as known variants. In fact "bracket", in terms of punctuation, properly refers to the whole class of symbols (( ), [ ], { }, < >...).

Note that the C standard itself uses “bracket” in the general sense in places (6.7.8 “30 Note that the fully bracketed and minimally bracketed forms of initialization are, in general, less likely to cause confusion.” - referring to the use of curly braces in initializations), and qualifies “bracket” in other places (6.5 “71 … subscripting brackets []”, “6.5.2.1 Array subscripting … 2 A postfix expression followed by an expression in square brackets []”). Rwessel (talk) 16:12, 25 April 2011 (UTC)

That's because the term "braced" would convey the wrong connotations. Just because a noun can be verbed, doesn't mean it should be. — DAGwyn (talk) 20:36, 14 October 2011 (UTC)

"Curly" and "square" are valid descriptors modifying the official nouns, and can be used for redundancy, especially given the use of "angle brackets" for <...>. Perhaps parens should be called "rounded parentheses" for the benefit of the Brits? — DAGwyn (talk) 20:40, 14 October 2011 (UTC)

The ISO standard name for the "{" character is left curly bracket; that is also the standard Unicode name for it, as well as opening curly bracket, and left brace. Likewise, the standard name for "[" is left square bracket, as well as opening square bracket. See the Unicode code chart. The Hacker's Dictionary entry for ASCII is also illuminating on this point. — Loadmaster (talk) 16:33, 28 April 2011 (UTC)

I happen to believe that parenthesis, bracket, brace is the One True Naming Convention for these glyphs, but since the British don't even know what a parenthesis is, there's no way that Wikipedia will ever be the place for it. The terms that best enable the full spectrum of international and non-technical users here to immediately grasp what's being talked about are what should be used here. —chaos5023 (talk) 20:50, 13 July 2011 (UTC)

Terminating strings with a NUL

The Criticism section has a new "terminating strings with a NUL" criticism with a bare link to a blog (which I only skimmed very quickly). My feeling is that the criticism is undue given C's history, and poorly expressed (the extra compiler cost is related to some cases where the compiler may be able to optimize the code, so the current wording is a bit off). The key point about the original terminate-with-NUL decision was that C has no built-in limit to the length of a string, something that I did not see discussed in the blog in my quick skim—the blog seems to suggest that adding a single extra byte to make a byte count field of two bytes would have been a better choice (i.e. have a two-byte length instead of a one byte terminator). That is just misguided, and four bytes is far too many for embedded controllers or indeed many applications at the time C was developed. A better criticism would be that C's strings cannot contain arbitrary data. I don't feel strongly enough to remove the new text myself, but wonder if anyone has comments, or a better source. Johnuniq (talk) 00:06, 13 August 2011 (UTC)

I found the source to be extremely biased though valid on a few points- namely security issues. I trimmed the comments somewhat, but I don't think the portions about the hardware, compiler, or performance costs are actual issues, but more of a sensationalism. The problem with the compiler costs argument is two fold:

The article makes no claim about what the vast number of optimizations that need to be done due to NUL-terminators.
The article doesn't quantify development cost or really say anything other than that NUL-terminators increase compiler development costs.

As for performance costs:

The article didn't quantify this other than to say bcopy/memcpy can be implemented more efficiently by copying word size chunks as opposed to byte size. This may well be true, but it is stated without any proof.

As for hardware costs:

Doesn't quantify hardware costs.
The article basically says that older systems using the addr+len model had ISA support for it. Then gives an example of another system having to add string NUL-terminator HW support. How is the latter more costly than the former?

More or less, if you examine what the article says, none of it really holds up. The problem here is that it appears to be mostly an opinion piece. I was troubled with removing it completely because the article is ACM though and appears to be a valid source that would probably be controversial to remove without discussion. Personally, I feel we should clobber it though if other editors agree. Or rewrite it into criticisms of string security w.r.t. buffer overruns. snaphat ► 01:17, 13 August 2011 (UTC)

This issue is generally known as "counted strings versus terminated strings" and has been the subject of numerous debates, analyses, and experiments. Counted strings have length limited by the counter's representation, but in most applications each string tends to not exceed a few rows of characters on a page or screen. Counted strings make some operations (e.g. concatenation and determining length) faster, but others slower. At the time C was invented, zero-termination was widespread practice in DEC assembly-language programs. If you want to invent your own counted-string package, I highly recommend representing the string objects by pointers to their first characters (just after the count) and null-terminating them also, so the pointers can be used directly with the standard C library functions. — DAGwyn (talk) 20:59, 14 October 2011 (UTC)

Ugh. I see this just got pulled, but NUL terminate strings *are* one of the major criticisms of C (as mentioned, they've "been the subject of numerous debates, analyses, and experiments"). Whether one agrees with that position or not, it *is* a major criticism (and this is not the place to debate whether it's a valid criticism or not valid). I think this should be put back, but the criticism section should be moved out of the syntax section. There’s even some justification for leaving the NUL terminate string issue under syntax, as the compiler *does* explicitly support those. Rwessel (talk) 00:15, 15 October 2011 (UTC)

language with extensions to C

"C has greatly influenced many other popular programming languages, most notably C++, which began as an extension to C." Is the C++ the only language with extension to C? or there are some other small languages (not notable) that I don't know? It looks to me that Ch has many extensions to C. The significant feature is Numerical computing (vs matlab/mathemetica), shell programming (vs C shell/Bash), embedded scripting and C++ class. However, ch is not an open source software and the number of users should not so significant comparing with C++. I would like to see wikipedia has a list of such languages. — Preceding unsigned comment added by 64.134.222.4 (talk) 15:28, 12 October 2011 (UTC)

If I understand your question, you're looking for languages that are a superset of C, or started that way. Note that C++ may have started that way, and retains a high degree of compatibility with C, but is not any longer a proper superset. A few languages have definately taken that route, Objective C being perhaps the most prominent besides C++. There have been other serious revampings of C (D, for example), that still retain much of C's flavor. Other's have retained little but a bit of the syntactical appearance (C#, Java). Also many implementations of C actually implement a superset languaged. GCC, for example, has dozens of extensions to standard C, and is, in effect, a superset of C. So the question is somewhat vague.

There have also been subsets. Embedded C and the MIRSA standards, as well as many subset implementations (many compilers for embedded systems, things like Tiny C).

Perhaps [List of C-based programming languages] would be a start. Rwessel (talk) 16:56, 12 October 2011 (UTC)

Java, C#, ObejectiveC, and D are not C compatible. They all upgraded C (not extending C) for the purpose of doing something better while keeping the C-like language syntax or style. If you write code in those languages, the existing C skill set cannot be applied. I mean all C functions you know cannot be used.

gcc, intel C compiler and Microsoft Visual studio have C extensions. but those extensions are minor. They mainly serves as the purpose of C compiler.

I read [List of C-based programming languages] and think it is more appropriate if we call it [List of C-like programming languages]. I thought it is a [list of C-written programming languages].

If we talk something extending C with significant features, we have C++ and Ch only (C compatible, not 100% though).

Also, it is easy to think C is a compiled language vs scripting languages like Perl. Maybe it is a good idea to introduce Cint and Ch about C scripting here? — Preceding unsigned comment added by 64.134.222.4 (talk) 15:30, 13 October 2011 (UTC)

Objective-C is a pretty strict superset of C. I'm still not quite getting what you want to do. Rwessel (talk) 18:24, 13 October 2011 (UTC)

Thanks. I think the page can be made more clear to the reader. 1) move "C has greatly influenced many other popular programming languages, most notably C++, which began as an extension to C." to the section "Related languages", add something like: "C has three superset languages: C++, Objective-C and Ch. They all serve different purpose". (are there any other superset of C languages?) 2) under the section "Related language", "C has directly or indirectly influenced many later languages such as Java, Perl, Python, PHP, JavaScript, LPC, C# and Unix's C Shell." Add C++, Objective-C, D programming language, Limbo, Go to the above list. 3) under the section "Related language", move the detailed introduction of programming languages C#, D language, Limbo, Go and Perl starting with "C# was designed in order to ..." to the page [List of C-based programming languages]. Too much space wasted to introduce the extended languages which are not compatible or superset of C. 4) "When object-oriented languages became popular, C++ and Objective-C were two different extensions of C that provided object-oriented capabilities.". it is well known that the scripting languages such as perl, python, php are popular nowdays, people intend to do more things in scripting. can we add: "When scripting languages became popular, cint and Ch offer C scripting capabilities"? however, both Cint and Ch are not as popular as Perl. — Preceding unsigned comment added by 64.134.222.4 (talk) 05:07, 14 October 2011 (UTC)

I think the lede is OK as it. It's supposed to provide an introduction to the topic, and should avoid going into too much detail. I'd agree with removing any specific influenced language reference from the lede, except for the huge importance of C++, so that's reasonably there.

FWIW, Unified Parallel C, Split-C, Cilk and C* are other examples of (not necessarily perfect) extensions to C. And that's hardly an exclusive list - those all focus on parallel programming.

I agree that the Related Languages section is a bit of a mess. It's disorganized, and while it's approprate to talk a bit about the important related languages, I think a few of those (Go, Ch, Limbo deserve at most minimal mentions). Perl doesn't need to be mentioned twice (it's inclusion in the "weakly" related list in enough). I think more just deletion of some of the detail is in order, no real need to move it to the list page, those sorts of things should really be covered on the language's page. Again exceptions for the really important ones. We also can't mention all the languages that C influenced, since there are so many.

As a first pass, what do you think about User:Rwessel/c-related? Feel free to edit that, BTW. Rwessel (talk) 07:05, 14 October 2011 (UTC)

I made a slight modification. It looks good to me. — Preceding unsigned comment added by 64.134.222.4 (talk) 07:32, 14 October 2011 (UTC)

I'm not sure that pointing C++ and Objective-C out as supersets (and neither is a pure superset, just to confuse things) really adds much over the prior paragraphs. But why mention Ch? I've never actually encountered in the wild, is there enough usage to consider it a worthy of mention? Why not Unified Parallel C too, for example? Rwessel (talk) 07:58, 14 October 2011 (UTC)

I read about Unified Parallel C. Yes, I think it is a good to mention it. That is the language I want to know when I learn C. The development of Split-C stopped since 1996. it is not necessary to list it. However, the number of users for both United Parallel C and Ch should not be so significant comparing with C++ or Objective-C. If the popularity is a concern for being mentioned, they can be removed. It is a good place to know those superset of C languages here though. No language will be 100% superset of C. Maybe it is good to point it out 64.134.222.4 (talk) 14:35, 14 October 2011 (UTC)

I went ahead and made that change (with a minor revision). Rwessel (talk) 18:44, 14 October 2011 (UTC)

It used to be the case that many programming languages were modeled after ALGOL, and now many are modeled after C. I think less should be said about related languages, with the sole exception of C++ which has close ties to C (several people attend both C and C++ ISO Working Group meetings), perhaps just an unannotated list (with Wikilinks). — DAGwyn (talk) 21:08, 14 October 2011 (UTC)

I don't necessarily disagree, but the new version does remove a bunch of the old fluff, and most of the related languages *are* now just in a list. I do think that Objective C is important enough to merit a mention. Rwessel (talk) 00:25, 15 October 2011 (UTC)