Talk:C (programming language)/Archive 7

Reasons for not promoting
Hi all,

I was very close to promoting this article to a good article. But I felt it was still in a state of transition and needed some further refining. My two main suggestions are:


 * Fix the citation tags.
 * Move the criticism section (4 screens worth) to a sub-page and summarize it in the main article.

Cedars 00:44, 7 August 2006 (UTC)


 * Since when has there been this disturbing trend to move only criticism off to a subpage? If anything, a discussion of pros and cons must take place -- not outright criticism. Dysprosia 00:49, 7 August 2006 (UTC)


 * Maybe it is my fault. I have done this for the Java criticisms section, because it has become very long and confusing for the reader and some of the critics could really be objected. I think we should have a normalized way to deal with pro and cons for computer languages. Some of them have no criticism sections at all : ADA, Basic, Fortran, C#, Python, Perl, Ruby (almost no critics). Some of them have several pages of them (this is the case for Java, and for C). The length of the criticism section does not say anything about what are the real cons for a language, so I think that to have a standard way to present pros and cons would be fair. Hervegirod 23:36, 7 August 2006 (UTC)


 * I agree with the idea that the criticisms section is unduly long compared to the rest of the article, and could be moved to a new (sub)article "Criticisms of C", with a summary mention of some of the main complaints. I think the citation policy is being carried to an unreasonable extreme here; except for the bit about optimization (which I think has rightly been removed), the flagged statements about C's ubiquity and significance are generally well established in the industry and known as such by personal experience of several independent contributing editors, who have as much credibility as any reference that could be cited, such as a survey in some trade magazine.  (Such studies usually exhibit poor statistical methodology anyway.)  If an article were to say that the Sun is very bright, would a citation be required? DAGwyn 10:24, 27 August 2006 (UTC)


 * I also think the "hello, world" example would be better as a separate, linked subarticle. DAGwyn 10:29, 27 August 2006 (UTC)
 * Speaking of the hello world example, the function prototype should be int main(int argc, char **argv). Is there a specific reason not to have this?Kreca 10:47, 27 August 2006 (UTC)
 * Both int main(void) and int main(int argc, char **argv) are equally valid definitions. If you are not going to use argc and argv, then why bother defining them?Mrjeff 09:24, 28 August 2006 (UTC)
 * That's right (there are these two distinct valid interfaces for main, according to the C standard), and even worse than that C99 allows the return to be omitted (for main only), automatically assuming return 0. I don't think it is useful to explore that in an introductory article. DAGwyn 20:49, 29 August 2006 (UTC)
 * Turns out that there is already a "hello world program" article, more general than just about the C example, so separating out the "hello, world" section would be problematic. DAGwyn 20:55, 30 August 2006 (UTC)


 * I moved the criticisms section to a separate article. It would benefit from some slight clean-up, in particular I didn't (yet) summarize the criticisms in the main page, just inserted a link to the new article. After that is done, the C article should be re-submitted as a "Good article". DAGwyn 21:58, 30 August 2006 (UTC)
 * I cleaned up the remaining "Criticism" section a bit more. It may be good enough to try resubmitting as a "Good article" now.  I haven't yet done that, in order to provide some time for evaluation of the changes and discussion, if necessary. DAGwyn 04:07, 31 August 2006 (UTC)


 * Doing so is not in adherance with NPOV, unless you title the page differently, and include countering viewpoints. Any page including criticism must be balanced or Wikipedia takes a non-neutral view on a topic, which is not permitted. Dysprosia 04:26, 31 August 2006 (UTC)
 * That is a misunderstanding of WP:NPOV. C programming language, criticism does not criticise C, it describes existing criticism of C (and, from a glance, in a reasonably neutral manner, neither endorsing nor rejecting this criticism). Moving this to a seperate article is fine. I don't know if the name is perfect, but the concept is ok. It could use some sources, though. --Stephan Schulz 06:46, 31 August 2006 (UTC)
 * No. Presenting only criticism without response or other positive views is unbalanced and hence presents a one-sided view on a topic. That is not NPOV. Dysprosia 12:47, 31 August 2006 (UTC)
 * Note first of all that I did not create the C criticism text — it was already embedded within the main C programming language article, and I was merely responding to the requirement expressed at the start of this discussion topic that the criticism be moved to a separate page. Next, note that Stephan is correct in his observation that the criticism text is merely reporting on a factual matter, and is fairly well balanced, not just negative POV.  Indeed, as one of the oldest proponents of C and a longstanding member of its standards committee, if I thought it had been too negative I would have added some counterbalancing comments to it. You can do so yourself if you think it necessary. What I am looking for feedback on is the act of moving that text to a separate article, not the (pre-existing) content of that text, which by the way now has its its own discussion page. DAGwyn 04:30, 1 September 2006 (UTC)
 * I'm not opposed to having the text. I'm opposed to it being the only thing in the criticism article (because, as I've outlined, doing so without balance isn't NPOV). There is no very strong reason that I can think of for having content based on analysis in another article. And as you suggest, I intend to look over the article for problems when I have some time. Dysprosia 02:06, 3 September 2006 (UTC)
 * Note the very first entry in this section, which seems like a pretty clear requirement to move the criticism section to a separate page. I think links are a useful tool for reducing clutter in main-line text.  Also, the criticism section does have a fair amount of balance — and it really is undeniable that several of C's characteristics can be problematic for some people in some contexts, so the overall gist of such a section has to seem somewhat "negative".  I did find a less-than-balanced piece of it a day or two ago and made it more neutral.  Further contributions would be welcome, but let's try not to turn the criticisms article into a debate. — DAGwyn 05:55, 4 September 2006 (UTC)
 * I wasn't planning to. I haven't had a chance to have a close read of the article, but if the article is as balanced as you say, then there's no need to call the article a criticism of C, but more an analysis of the language with issues that people have found. Dysprosia 07:49, 4 September 2006 (UTC)
 * Criticism is not necessarily negative! --Stephan Schulz 08:28, 4 September 2006 (UTC)
 * This is true, but it's most common connotation is negative, and may be construed as such. That is undesirable. Dysprosia 12:05, 4 September 2006 (UTC)

Forth is lower than c
Forth is used quite a lot in bios or embedded devices where size is a issue. The new intel and amd64 are apparently written in plain c. Allix Fri Sep 1 13:59:01 BST 2006


 * So how is this supposed to bear on the C article? Also, your second sentence makes no sense. — DAGwyn 08:01, 2 September 2006 (UTC)

Requested move
C programming language → C (programming language) – Conformance with WP naming conventions LotLE × talk Note: Please notice the below info box. This is not a poll about C specifically, but about PLs in geeneral, many (but not all) of which use the pattern "FOO programming language" rather than the general WP disambiguation pattern "FOO (programming language)".

Burroughs MCP use of ALGOL?
I thought MCP was written primarily in ESPOL, which was a proprietary SIL that somewhat resembled ALGOL. — DAGwyn 09:34, 2 September 2006 (UTC)
 * I checked the reference manuals, and ESPOL is closely enough related to ALGOL that there is no need to adjust the current statement in the article. — DAGwyn 21:43, 7 September 2006 (UTC)

Failed GA nomination
I failed this article due to the fact that there are only nine references for a 49 kilobyte article. Besides that, it's great! Some P.  E  rson  00:06, 9 September 2006 (UTC)

Hello, world example
I tried using two different compilers (VS and gcc) and neither compiled main { printf("Hello world"); }. They both assumed that main was an int and both assumed a default return value of 0, however they didn't "auto-include" stdio.h, and therefore they both gave a printf not defined error. Are you sure that it is correct? Did anyone try to compile it? --Swalot 00:25, 17 September 2006 (UTC)


 * If you would have read the article closely, you would have seen these sentences: The above program will compile correctly on most modern compilers that are not in compliance mode. However, it produces several warning messages when compiled with a compiler that conforms to the ANSI C standard, and won't compile at all if the compiler strictly conforms to the C99 standard.
 * The example following it is presumably what you want. Dysprosia 01:48, 17 September 2006 (UTC)
 * I did read it closely, and that's why I used the most recent versions of VS and GCC, without the ANSI flag. And it wasn't a warning, it was an error. --Swalot 02:26, 17 September 2006 (UTC)
 * gcc accepts it fine:

$ cat > test.c main { printf("blah\n"); } $ gcc test.c test.c: In function 'main': test.c:1: warning: incompatible implicit declaration of built-in function 'printf' $ ./a.out blah
 * and that was from gcc 4.0.3. Not including header files doesn't mean that your program can't be linked. Dysprosia 02:38, 17 September 2006 (UTC)
 * ok, sorry then :( --Swalot 03:16, 17 September 2006 (UTC)
 * Don't be sorry, at least we've resolved the matter :) Dysprosia 05:19, 17 September 2006 (UTC)
 * Note that the first form of the program was meant to illustrate what C was typically like in pre-Standard days. Perhaps that should be made clearer. — DAGwyn 06:06, 18 September 2006 (UTC)

C
Sir Since default data type of pointer variable is int, then how can it store value more than 32667. your faithfully Neeraj Pandey


 * This page is for discussions about the Wikipedia article "C (programming language)". Questions about C programming should be posted to the net newsgroup comp.lang.c instead.  However, the simple answer is that your statement is wrong: pointer variables have their own specific types, which are never type "int", and while many C implementations do allow pointer values to be converted to and from some integer type without loss of information, that type isn't necessarily plain "int".  Also, on many platforms type int can represent values much larger than 32767. — DAGwyn 19:22, 29 September 2006 (UTC)


 * Anyway, pointers can store calues till 65535 on 16-bit compilers or 4294967295 on 32-bit compilers. On 16 bit compilers, writing this should work: int far *n = 0 ; --200.126.153.25 21:36, 17 August 2007 (UTC)

C++ superset of C
Unless my memory is going, the original implementation of C++ was a preprocessor that translated the language into C, and then it was compiled with a regular C compiler. That is why I said it was originally a superset of C. Of course, saying it is nearly a superset of C is correct regardless of the state of my memory. ;^) wrp103 (Bill Pringle) 21:31, 27 October 2006 (UTC)


 * It is true that early implementations of C++ (and its forerunner "C with classes") used a preprocessor. However, they completely parsed the source language, and interpreted some things differently from how C compilers interpret them, so that the generated C source text was often not just a simple "copy through" of the C++ program source text.  For example, "extern int foo;" declared the function as definitely not accepting any arguments (what is now known as "extern int foo(void);" in Standard C), whereas in C the same syntax has always declared the function as having unknown argument types.  Also, character constants 'x' have type char in C++ but type int in C.  There are other differences, too; see Tribble's page for more detail.  There is a "common subset" of C and C++ that some programmers try to remain within, so that their code works under compilers for either language.  But it's smaller than "all of C". — DAGwyn 06:13, 31 October 2006 (UTC)


 * Some versions of C++ still output C, and then expect you to compile that using a C compiler. However, some Haskell compilers do the same, and I don't think anyone would claim that Haskell is a superset of C :) Mrjeff 10:23, 31 October 2006 (UTC)
 * C++ came about before ANSII C, so the compiler didn't complain about how many arguments were used. What you are describing might be how some C++ compilers work now, but it wasn't the way the first OO versions of C worked. wrp103 (Bill Pringle) 14:20, 31 October 2006 (UTC)
 * Well the first C++ compiler was Cfront. describes how it worked. The "C with classes" compiler could be described as you say, but the first compiler for C++ did it's own checking. Mrjeff 16:54, 31 October 2006 (UTC)
 * Yes, Pringle is simply wrong. The relevant "compiler" is the C++-to-C translator, not the back-end C compiler; the Haskell example should illustrate the point that one can't infer any similarities between the two languages just from the preprocessing construction.  Even "C with classes" did function parameter type checking (at least within a translation unit).  The types were also enforced for external names via the "name mangling" that embedded that type information into the interface, so that a mismatch would be caught by the linker.

A small set (around 30) of reserved keywords
Technically correct, and true in it's original context (as a system language), but a bit misleading. Look for example at the "Hello World" example. Is that written in C? With C? or what? Which part of C is sprintf? And if it's not part of C, why is it the classic example? Which part of the 'characteristics' section tells you that standard C includes standard libraries? I don't have a solution, but there is a disconect between that typical definition of C, and the language as actually used: that definition is of only technical importance, and not related to the language being demonstrated, which has hundreds of key words, which you can redefine, but don't. 218.214.148.10 01:37, 6 November 2006 (UTC)
 * C is fairly cleanly partitioned into: preprocessor, language, and library. This should probably be made clearer at the start of the "characteristics" list. DAGwyn 20:56, 7 November 2006 (UTC)
 * 218.214.148.10, the use of library functions was well-known by the 1970's, where a library call was understood not to be part of the language, but a call to a facility provided by the operating environment, which tremendously simplifies the programming, and allowed a clean separation between implementation and language design. Some examples of this point of view can be found in languages like Jovial, which had no I/O. Thus Hello, world was an advance, because you could write a program without also writing the I/O library. See Free On-line Dictionary of Computing for more of this type of CS history. --Ancheta Wis 04:16, 14 December 2006 (UTC)
 * So sprintf is understood to be a call to the operating environment? That may have been true for a VAX, but it's not a helpful statement about C in general. (david) 150.101.166.15 02:27, 20 June 2007 (UTC)


 * Actually, sprintf is a call to the run-time environment, not the O/S. Section 2 were generally O/S calls, while section 3 functions were to the runtime. -- wrp103 (Bill Pringle)  (Talk) 04:51, 20 June 2007 (UTC)