Talk:C /Archive 1

Archive 1

Archive 2

Archive 3

→

Archive 5

Pronunciation

Should there be a remark about pronunciation?

Arguments supporting a pronunciation remark:

• Some people may be confused by the token "C ".

Arguments supporting nod pronunciation remark:

• Pronunciation notes should only be added when pronunciation differs from what you would expect. C is pronounced exactly like you'd expect.
• The C ISO standard does not explicitely standardize the pronunciation.
• Defining pronunciation as "see plus plus" suggests that it's pronounced "see plus plus" by everybody, while non-English speakers usually pronounce it in a way that matches their language.

My personal opinion is that there should be no pronunciation remark. - Eelis 17:44, 2005 May 21 (UTC)

"using"

I think the discusion of using in Exapmle 4 should be removed. The article should not try to be a C style guide. Anyway the given rule itself is debatable (see e.g. "C Coding Standards, Herb Sutter and Andrei Alexandrescu, 2005).

Etymology of "C "

future note to whoever updates the C definition of "C " or feels the need to clarify it:

• Does your statement reflect a strict definition of *what it does*, or does it help illustrate *why the language is called C *?
• Is tangential syntactical clarification about this statement relevant to the goal of explaining why the language is called C ?
• Is it good enough already or are you just changing it for the hell of it?

For example: stating that "C is a C expression that stands for postorder incrementation of the variable C" is a great definition of C syntax. Yet it does almost nothing to explain why there is a language called C and how that relates to a language called C.

This is not addressed to anyone in particular, but to the inevitable next person to update this page so please don't take offense.

Finally, I changed it by adding a quote from Stroustrup, and an explicit statement that yes it is a play of "words". Perhaps "from the horse's mouth" will do.

---

There is nothing inaccurate about stating that is an increment operator. Your comparison statement has no relevance outside a discussion of postorder-preorder discussion--and that discussion would be covered most likely in C programming language.

BTW, wouldn't C == C since its not incremented yet?

---

I removed

[Technically the pun is inaccurate; C < C in both languages.]

because it's wrong. In both languages, the order of evaluation is unspecified. If the right-hand side is evaluated first, then the expression as a whole evaluates to false or 0 (depending on the langauge). This assumes that the type of C is a built-in arithmetic type, of course. --Zundark, 2001 Nov 1

---

Any expression with "C" and "C " both occurring between sequence points (and comparisons are not sequence points) is officially undefined, which means the compiler is free to do anything at all. That's the nature of C, to leave things up to the compiler. Other expressions with "c " (by itself) have the value of "c", if that value is used. By itself, it is used only for the side-effect. At any rate, the statement is not only inaccurate, it's totally irrelevant smart-ass nonsense that provides no useful information to the reader about the topic here, so by deleting it we're not deleting "content", because the statement has no content. The absolute undeniable facts are these: C programmers often use the expression "c ", by itself, to increment the variable "c". Stoustrup chose to use this common and useful idiom to name his language. Even if you modified the statement to be accurate, obscure details about particular operator behavior should go into some different article that covers such details. --Lee Daniel Crocker

Amen! Thank you for stating so eloquently what I was trying to say... --Alan D

---

But, in fact, you ARE deleting content. Moreover, in this context, it is not an "obscure detail" about operator behavior, but a widely-known observation about the pun which underlies the name of the C programming language. Your description of this information as "totally irrelevant smart-ass nonsense" is simply incorrect. I am frankly somewhat puzzled as to why you are reacting so emotionally to including this information. I suppose it has something to do with the way that programming languages seem to inspire almost religious fervor in some people. You evidently seem to think this information somehow denigrates C or Stoustrup. Of course that's ridiculous. But it's clear that your actions are an inappropriate attempt to censor Wikipedia content. -HWR

---

Have you even taken a high school english class? Did they teach you how to write papers? Nobody is excising it based on a "denigration of stroustrup". It was deleted because:

• The expression "C ", as it is used in C, C , and the _name_ "C ", is sitting alone. Any argument about operator or comparison precedence is not relevant to the discussion because it has ONE OPERATOR and NO COMPARISON.
• The statement is technically incorrect, as Zundark and LDC have pointed out because the order is undefined (a point I was not aware of, something I freely admit.)

In other words, it was deleted because good editing requires it. Not everything is purely about content here. Lets suppose that the statement (C ==C) _was_ true. We still would not include this information because it is not relevant to the topic on hand. No one mentioned comparison, so any comments on order of evaluation in comparisons should be relegated to somewhere else. This is called GOOD WRITING.

You want to write about it? Here's how you might do it and retain document quality. Note something like

(stroustrup could have chosen " C" as well. See Operator precedence.)

Then write to your hearts content in Operator precedence about these niggling little points that are suddenly relevant _in proper context_.

No one is giving up, because we care about the quality of wikipedia. Alan D

---

First, the point I was attempting to make really has nothing to do with operator precedence or the order of evaluation of operands. It has to do with the value of the expression "C ", and it is perfectly relevant in this context. In fact, Stroustrup himself mentions it in precisely the same context. I readily accept the criticism that the point could be better expressed, in which case it should be rewritten, not deleted. Good editing does not require the deletion of content. If you are unable to rewrite it to your stylistic satisfaction, then you should leave it in place for someone else. And yes, I did take english class in high school (at least I think so, it was a long time ago). And no, personal insults are not appropriate conduct here either. -HWR

---

Hank:

first, I formally rescind my insult with apologies. On the other hand, I (and I'm sure a few other contrubuters here) resent the implication that anyone is trying to _censor_ content. I also happen to think that the notion that anyone would "censor" information like that for some bizarre reason is kind of funny. Now I think that I have a fairly good grasp on the C language. Lee here has written quite a bit in the Java language page and is quite a smart fellow himself, and it would seem that Zundark knows what he is talking about as well. Yet thus far your point has eluded all of us. This could be entirely the result of our own failings, but the burden lies on you to demonstrate why this point is valid, or else the basis of the wiki process requires us to edit the page.

I'm still at a loss as to why the information is important, especially if it has nothing to do with order of evaluation. Perhaps the best way to demonstrate this would be to produce the strousrup quote you refer to. I have read his book on C (well, a good chunk of it) including the part where he mentions the naming of C . Thats where I got his quote. He didn't see fit to mention your point there either. And please don't produce a quote that has nothing to do with the naming of C .

And lastly, I don't think anyone is acting emotionally about the quote itself, but as a result of our repeated lack of understanding as to why this is relevant information while at the same time someone else sees it as indispensible. This has degenerated into a flame war, and I don't think anyone wants that. I will have nothing more to say on the subject save a personal apology if you can demonstrate to the community's satisfaction why this is relevant.

---

Alan,

Apology accepted; no big deal. I have attempted a rewrite I hope you'll find acceptable. Let me know if you feel there's still a problem.

---

As it is currently written (some say c would have been better...) it is now more accurate and I think better fitting. I suppose a bit of culture isn't out of place, so my earlier "irrelevant" comment is retracted. --LDC

Tutorial

C is now one of the widest-used languages, due to the widespread use of Unix and the market monopoly of Microsoft. I think it deserves a small tutorial in Wikipedia.

I would like to write the tutorial (actually, two: one for programmers familiar with other languages, and one for people with no programming experience). The tutorials would be on a set of separate pages, with a prominent wiki in this article.

However, I don't want to waste my time and energy, so I ask you: does anyone have an opinion as to whether such a tutorial belongs in Wikipedia?

David 14:38 Dec 26, 2002 (UTC)

---

There already is a C Wiki and Tutorial at

http://www.gnacademy.org/twiki/bin/view/CPP/WebHome

---

I don't think Wikipedia is the place for tutorials. It's purpose is to document information; for a programming language, there should be a general description, history, common usage scenarios, etc., and perhaps some short examples. Links to tutorials like the one mentioned above would be appropriate. Wesley

---

Topic name, again

Is this language ever referred to as C Plus Plus...or should it be moved to CPlusPlus? Pizza Puzzle

The only references to CPlusPlus I can find are used as abbreviations in such things as email addresses and URLs. The most common name of course is C but I'm pretty sure we have it here because that would throw off the search engine. Hephaestos

I guess C plus plus gets way more sites than Cplusplus; however, most of these appear to be lowercase, not uppercase. Pizza Puzzle

I don't think there's much point in moving it at the moment. I'm still hoping that C will be made to work eventually, then we can move it there. --Zundark 10:03 May 14, 2003 (UTC)

righto Pizza Puzzle

---

Etymology of "C ", again

Moved from the article

Some C programmers have noted:

• If x=3 and y=x , then x=4 and y=3
• However, if y= x, then y=4 and x=4.

Following such reasoning, a more proper name for C might actually be C. However, other C-programmers do use the expression "c " to increment the variable "c".

Is this really significant to note? -- Taku 19:59 16 May 2003 (UTC)

Well, the guy who designed C , he thought it was worth noting that some people make this argument; although he does disagree with them. Why wouldn't it be significant? Its been a part of this article since it was first created 2.5 years ago. Pizza Puzzle

how long do I have to wait for a response before I can revert the deletion? Pizza Puzzle

Sorry for responding late, you can revert if you want without wating for me for a long time. I am wondering if you think it is significant to note why don't you also put the reason why. I mean you can say the designer of C (I know his name but can't remember how to spell), you can say that in the article too. Oh by the way the length of history in here doesn't matter much. There are a lot of articles that are worthless, POV'd but have remained years unfortunatelly. -- Taku 23:09 17 May 2003 (UTC)

Are you suggesting that this information is in some way POV? I can't see how its POV. Pizza Puzzle

No, not POV problem at all. What I meant is that if the readers see that mention, they may wonder so what. Some C programmers? Who are they? Why is it important. If it should be noted, it should be cleared why it should be noted. -- Taku 00:22 18 May 2003 (UTC)

---

"alias types"

What are "alias types"? I don't think this is a common C term, whatever it refers to... the corresponding article hasn't been written yet ;-)

I assume it refers to references, but the sentence is not at all clear about that. It might also refer to the typename or typedef keywords. Someone should clarify the sentence.

C has typedefs and free of aliases. So, if Author is using such keywords he has to explain something like: *mentioning aliases I refer to typedef constructions

---

Why is C not a subset of C ?

Any insight as to why C is not a subset of C ? I'll grant that C99 is not a subset; however, as I understand the standard (and believe me, I can be very wrong about this), C 98 officially supports the entire C89 language and libraries. If I am not mistaken, that would effectively mean that C89 IS a subset of C .

No, it's not a subset, though it's very close. The following is an example that I wrote some time back to show one of the differences. Compile it as C and run it. Then compile it as C and run it. The reason it behaves differently is because in C the foo in the print statement refers to the typedef, but in C it refers to the struct. --Zundark 09:25, 15 Oct 2003 (UTC)

#include <stdio.h>
typedef int foo;
int main(void)
{
    struct foo { int x[2]; };
    char *arr[] = { "  ", "" };
    printf("C%s\n", arr[sizeof(foo)==sizeof(int)]);
    return 0;
}

Thanks for the example. I see what you mean. What surprised me though wasn?t so much the scoping changes from C, but that struct foo{...}; doesn?t lead to a name conflict in C. I assume that is because in C we say;

foo x;        /* Instantiate an int */

struct foo y; /* Instantiate a foo struct */

and so the names are unique?

Yes. In C you can't refer to struct foo as simply foo, so there' s no conflict. --Zundark 20:19, 18 Oct 2003 (UTC)

---

One of the important things worth mentioning to explain the incompatibilities between C and C is the matter of symbols and linkage.

1. You can use (in both C and C ) two keywords, static and extern to manage the object scope inside the linkage bundle (instead of static, it is more proper to use anonymous namespaces in C , however). But in C constants are "static" by default, while in C constants are "extern" by default (like other symbols). For variables, declaring them extern without initialization means importing the variable, but with initialization it is the same as without extern. That's why in C , if you want your constant to be visible outside the compilation unit, you must declare it extern and initialize. Otherwise it will not be able to import from another compilation unit, unlike C.

2. C uses only vague linkage, while C uses both strict and vague linkage. Vague linkage means that when the linker found two symbols with the same name, the first found is taken. When the linkage is strict, such a situation is a linker error. C uses strict linkage for all explicit objects and vague linkage for implicit objects (generated by compiler, inaccessible for user). In consequences:

• In C you can declare global (external) variables without modifiers even in header files; linker will refer all bindings to the same variable despite that every compilation unit created its own one
• In C you must provide exactly one declaration of an external variable; place the variable in a selected compilation unit and import this variable to other compilation units using extern

The same concerns functions; two functions with the same name will cause conflict. However this does not take place in case the compiler produces the "outline version" of an inline function. Such a function undergoes vague linkage. However vague linkage makes the linker select first found definition. That's why inline function must be defined the same way in every compilation unit, which means in practice that they rather should be defined only in header files, or defined local for compilation unit (inside anonymous namespace).

--Ethouris 20:01, 14 Apr 2005 (UTC)

Such level of details looks as overkill to me. No one will use Wikipedia to learn C . Pavel Vozenilek 21:53, 14 Apr 2005 (UTC)

"hello, world"

Just wondering, isn't this is the simplest "hello, world" program...

#include <stdio.h>

main() {
printf("Hello, World!");
}

and isn't that the one that's used more often, as it's like 10 letters in total (and I exaggerate)?

That isn't standard C , so I hope it's not used too much. I've now simplified the one in the article by removing the unused arguments to main; the "return 0;" could also be removed (as the standard has a special provision for implicit return 0 at the end of main()), which would make it almost as short as a rectified version of yours (and with the advantage of not using a deprecated header). --Zundark 09:19, 13 Nov 2003 (UTC)

Just a note... Since the output -- "Hello, World!" -- is a string, puts could be used in place of printf (and without a '\n', since puts adds that). From a programming perspective, it's not really much simpler, but where efficiency is concerned, it's probably a teensy bit simpler. --rAS 07:42, 26 Mar 2005 (UTC)

Dear, Author. Your example with printf is simple but it does not reflect C at all.

Regarding omitting return 0; I don't think it should be done in example since the article is kind of brief talk on topic of C .

It actually is standard C , except for having no return type, but stdio.h is only provided as a compatibility feature (it's described that way in the standard), as are the C libraries themselves.

---

Massive Edits Forthcoming

The page for C is well intentioned, but needs massive revision and expansion by someone who knows the language well.

I will be revising this article shortly. (I have already submitted two minor corrections.)

---

Technical Overview Changes

[The Wikipedia really needs ChangeLogs; maybe it has them and I'm just a newbie.]

I'm STL, by the way.

My changes addressed these issues:

1. The language itself, and not a given C program, consists of the Core Language and the Standard Library. 2. The Standardization Committee talks about the Core Language without scare quotes; thus, they should not be used here. (I like to capitalize Core Language, but that breaks the wiki-link, and since the capitalization isn't always used, I am content to leave it uncapitalized.) 3. The mention of "organized into statement blocks" was irrelevant and in any case is linked from the core language page. 4. Mentioned how the mighty C Standard Library contains the STL and the C Standard Library. 5. Removed the assertion that the C Standard Library is written in "core C". That statement is absurd. The Standard Library is traditionally implemented in C itself. 6. Removed the explanation that the Standard Library consists of "generic functions and classes"; that statement is bland and says nothing. A description of what the Standard Library /actually/ contains, in detail, would be good. 7. Expanded on how non-Standard libraries can be used with C .

---

C Examples Changes

Reworded Example 1 slightly. It previously said "this shows the core of the program". That was incorrect: it was a complete strictly conforming C program.

FIXME: A definition of strictly conforming would be nice.

"main() function" used to be in scare quotes. Unnecessary.

"main() is the highest-level function of a C program." is wrong, as C does not have nested functions. Saying that main is the "highest-level" is confusing. It is better to use the Standard phrase for it.

The comment "// return terminates functions" was eliminated in favor of a more extended discussion on main's return type and related heresies. If necessary, I would not be opposed to the reintroduction of that comment.

Example 2 is new and shows how return 0; can be elided from main() in C . Many people are unaware that this is good style in C .

Example 3 has been corrected to use std::endl instead of a newline character. The original manages to do the exact same thing, but only because output streams are guaranteed to be flushed during a successful termination. Using std::endl is better style and clearer to read.

STL 22:54, 2 Dec 2003 (UTC)

---

The void main() heresy

I didn't invent that phrase, and I don't think it consists of a "point of view". In any case, leaving in the factual statements about the return type of main() is fine, I guess.

In _C Unleashed_, chapter 2, page 54, Richard Heathfield devotes 3 pages to "The void main Heresy".

Since the Standard flat-out declares that int is required, it's not really a point of view to say that void main is heresy.... but whatever.

STL 23:11, 2 Dec 2003 (UTC)

---

Yeah, I didn't mean to use that edit comment, it's more like "removing redundancy". The restriction of void main() is really only pertinent to the Standards - which was duly mentioned. Saying void main() is heresy goes a little bit over the top too, and it was already mentioned in the previous paragraph, it doesn't need to be said. Furthermore, some variants of C - I'm thinking of the Plan 9 variant of C do use void main() and signal return status with exits(0) or whatever. Dysprosia 23:16, 2 Dec 2003 (UTC)

---

I agree with the change if it's in the interests of removing redundancy.  :->

A language can use void main(), or double main(), or vector<unsigned char> main() - it just won't be Standard C or C .

STL 23:23, 2 Dec 2003 (UTC)

---

The statement that <iostream> "contains the machinery for std::cout and std::endl" is not correct according to the ISO/IEC 14882-1998 - you need <ostream> for std::endl. I know this is generally considered a mistake in the standard, but the way we had it before was correct without caveats, and was also simpler. The statement that using \n is a hybrid of C and C is absurd, since it is prefectly valid and non-deprecated C . Also, the statement that std::endl is more readable is a matter of opinion, and therefore shouldn't be in the article. --Zundark 10:13, 3 Dec 2003 (UTC)

---

Interesting. I was truly unaware that you could elide return 0; in C99.

STL 17:46, 4 Dec 2003 (UTC)

---

SCO

Removed from article

At least, that was the case for most of the history of C . SCO has claimed that it owns C via its purchase of UNIX interest from Novell, and it also claims that customers frequently comes to it to license C . However, SCO has not billed or sued anyone over C , and according to Bjarne Stroustrup, it is ISO who owns the standard upon which all C compilers are based.

This comes from an external link I just removed from the article. The link contained an interview with the CEO of a software company. The CEO was extremely slopping in his language and made a gaffe... saying that his company owned C (presumably he meant "pieces of C code")... but hardly something to be given much attention in this article. Pete/Pcb21 (talk) 18:32, 4 Dec 2003 (UTC)

namespace std, headers

I removed the following:

Note however, that the current ANSI C standard recommends that we specifically mention "using namespace std;" before referencing any standard objects. Also, it is recommended for good programming practice that header files specific to C be mentioned without the ".h" extension viz. "#include <iostream>" instead of "#include <iostream.h>.

because as far as I'm aware the first statement is not true (references?) and the second refers to pre-standard headers; it's not "good practice" to use <iostream> over <iostream.h>, it's wrong to do it any other way. -- Lady Lysine Ikinsile 07:08, Jun 11, 2004 (UTC)

The C Inheritance section

Also, in C  , a class must mention whether it will inherit the public members of the
class or the protected members.

I think the last two word should mean "private members"? Protected members can never be used by inherited classes, but the private ones can, by specifying a "friend" keyword. (IIRC) --Kenny TM~ 14:28, Jul 15, 2004 (UTC)

No, private members can never be used by derived classes (unless they are explicitly friends: this would be a strange design, though), whereas protected members can—that's what protected is for. However, I still don't understand that sentence. I assume it's referring to "class D : public B" vs "class D : protected B" and so on. In any case you don't have to specify that—it defaults to private inheritence. I'll remove that sentence until someone can come up with a better wording. —Lady Lysiŋe Ikiŋsile | Talk 14:34, 2004 Jul 15 (UTC)

English Usage: "comprise"

81.131.200.210 said "comprises" -> "consists of"; "comprises" means "makes up", not "is made up of" and changed the article accordingly. That's actually backwards; see this page. Josh Cherry 23:26, 28 Jul 2004 (UTC)

Based on M-W's definition, 2 : to be made up of <a vast installation, comprising fifty buildings -- Jane Jacobs> I have reverted this edit. —Lady Lysiŋe Ikiŋsile | Talk 00:57, 2004 Jul 29 (UTC)

Incorrect example

The example given in the "C is not a subset of C " section is wrong, because it's possible for sizeof(int) and sizeof(char) to be equal. A correct example can be seen in one of my earlier comments on this page. Does anyone have a better example? Do we even need to give an example? --Zundark 16:49, 30 Aug 2004 (UTC)

C programming language has a nice list of differences (well, I am the one who started it). Maybe we could have one separte article discussing historical connection and differences in specifications (It is extremely important that we make sure what version of C and C we are talking about). -- Taku 19:00, Aug 30, 2004 (UTC)

Oh, and regarding sizeof(int) and sizeof(char), I think what matters when sizeof(int) != size(char), then what the value of sizeof('a') matters. It's a famous example (though I doubt it has practical problem much.) -- Taku 19:00, Aug 30, 2004 (UTC)

It seems to me that this does not illustrate the fact that C is not a subset of C . The code shown is valid C and valid C . It just (possibly) behaves differently when compiled as one or the other. Josh Cherry 22:57, 30 Aug 2004 (UTC)

The example is also incorrect code in both languages because it uses printf without declaration or inclusion of headers. Here is another example:

 int foo ()
 {
   return 2 //* */
         -1;
 }

foo returns 1 (2-1) as a C function, and -2 (2/-1) as a C89 function. Byrial 18:40, 20 Oct 2004 (UTC)

Forums Link

I have added a link to a small programming forum; actually only the C section of it. If you have objections tell me here before you delete it, since I'd like to know why. There's no real policy on linking to forums anyways.Cap'n Refsmmat 22:23, Nov 27, 2004 (UTC)

Wikipedia is not a link collection. If an article has external links, they must be of high quality and relevant to the article. So: No, there is no specific policy on linking to forums. In fact, one might say that the C page already has a link to a forum (kind-of): c2. At c2, several rather respected OO people hang out, and it has existed for a long time, proving itself valuable.

About your programming forum: I wish you luck with your forum. But: I'm sorry, it's just not interesting. I've noticed that you have put links to forums of yours in several articles (and I've removed most again). Please: Don't use Wikipedia as a publicity machine.

TroelsArvin 23:31, 27 Nov 2004 (UTC)

Please consider: Linking to forums on the Village Pump page. Cap'n Refsmmat 00:43, Nov 28, 2004 (UTC)

Pointer casts

From the article: Also C is much stricter about various features, including not automatically casting between pointer types

This is spoken with some authority but I believe that it is wrong. As far as I know, C will automatically cast between point types. If you take the address of an int and then attempt to pass that to a function that is expecting a float pointer, no compiler will complain. Anyone want to confirm this?

The text is correct, except for the technical terms; a cast is always explicit. What is meant is an implicit type conversion. --Mellum 14:22, 30 Nov 2004 (UTC)

Actually C will perform implicit type conversion from derived class to base class, as is convenient if not necessary for object oriented programming. But the conversion from int* to float* causes this error message on my compiler:

test.cpp: In function `int main(int, const char**)':
test.cpp:21: error: cannot convert `int*' to `float*' for argument `1' to `void
   troep(float*)'

Example 4

Seems to me to introduce too many concepts at once. This is only intellible to people who already know about the STL.

Seems to me it's a sample, not a tutorial. Samples should reflect real use, and since the 'stl' is a real part of C , samples should reflect it. None of the examples are particularily intelligible to someone who doesn't know any C at all -- how exactly could they be? Iamo 23:30, 28 Dec 2004 (UTC)

Never mind, looked again and it is pretty complicated. I don't think it needs much simplifying, but it could use a little. Iamo 23:34, 28 Dec 2004 (UTC)

"no longer a language called C "

In the "Technical overview" section, there is the following text (originally from 82.69.39.138, 2005 Feb 3):

It is important to realize that there is no longer a language called C ; the term C denotes a family of related languages, each usually a slightly incompatible superset of a previously defined one. Early members of this family used to be identified by version number, later members are distinguished by the year in which that specific language has been standardized.

What are these version numbers - can someone give examples? (Editions of Stroustrup's book?) Similarly, what are the years - revisions of ISO 14882? Are there serious incompatibilities between different ISO-standardised versions of C (e.g., the article mentioned 1998 and 2003), and do people often refer to variants of C like this in practice? -- JTN 21:47, 2005 Mar 4 (UTC)

Informal names: like C 98 means latest standard. New version is (few small changes aside) compatible superset of previous one. People don't use version numbers; most often C mean the C 98 variant: older compilers are not used much and old code base is mostly thrown out (or kept w/o active maintenance). Pavel Vozenilek 23:00, 26 Mar 2005 (UTC)

Not sure whether TreyHarris' recent revision is intended to address my comment; if so, I don't think that it helps. I imagine that the closest thing to an "official" view in this context is ISO's, and if ISO can be said to have an opinion at all, I expect it's that C is ISO/IEC 14882:2003 and nothing else. (I think that 'officially' is too often a weasel word.) -- JTN 15:09, 2005 Mar 8 (UTC)

This remark is pure nitpicking. Likewise, there isn't one language called C, Java, Visual Basic, or PHP either... Wouter Lievens 21:45, 26 Mar 2005 (UTC)

I agree. It should be removed. Pavel Vozenilek 23:00, 26 Mar 2005 (UTC)

Why "Plus Plus"

and not "plus plus", in the title? I was thinking of moving this, but there might have been some issue already? Dysprosia 22:57, 9 Mar 2005 (UTC)

I suspect some historical reason, maybe some technical one. You try to move this, and you may not able to do so. In any case, I don't know why Plus has to be capitalized. I don't think Plus is a proper noun like War in World War II. -- Taku 23:36, Mar 26, 2005 (UTC)

I've now tagged this talk page with a requested renaming to "C plus plus". --Fredrik Orderud 19:43, 25 September 2005 (UTC)

Done. Let me know if everything checks in okay. --HappyCamper 23:30, 26 September 2005 (UTC)

Searching for "C " from the search bar turns up many irrelevant hits. Apparently the is being understood as search modification symbols. Also, when linking to this article from other wikis (of type WikiMedia), [[C ]] does not link correctly, as in: C . Anyone know why? // Brick Thrower 05:00, 15 January 2006 (UTC)

using directives

The article says:

In this example, a "using directive" was used for brevity though in a real-life program, its use should be much more restricted. "Using declarations", which are more specific than directives, are usually recommended :

You hear this occasionally, but it's pure nonsense. You shouldn't put using directives (or declarations) in header files, but in implementation files they can and should be used freely.

Agreed. Most professional programmers I know put common namespace using directives at the top of the cpp file, and deal with with potential conflicts by simply using a fully qualified name as required. It would be ridiculously cumbersome to add a using directive inside each function. This would only be done if there were many naming conflicts between several namespaces, and it was more trouble than it was worth to use a global directive within the cpp file. I'd recommend removing that line.

I don't think that was a header file in example. Look at functions. In header files you do not put their implementation. Only functions declarations should be included in Headers. Consequently, author is free to use using directive. Moreover I guess it is up to ones coding style.

By the way in modular Programming Style it is useful to put some using directive in header. Imagine you are defining a Date module.

Main header that should be included by other files and determining interface:

Date.h

... namespace Date { void setDate( const std::string &); ... } using Date::setDate; ...

Put implementation details in another file:

Date_implementation.cpp

#include "../Date.h" void Date::setDate( const std::string &roNEWDATE) { ... } ...

In such architecture user always has access to Date::setDate function so he doesn't need to specifically add any directives. [look at stdio.h it includes cstdio.h and makes std namespace open]

OpenMP

How about a few lines of OpenMP implementation in C ?

OpenMP is a nifty specification, but what does it have to do with basic C ? I'd recommend adding this code to the OpenMP entry in Wikipedia: http://en.wikipedia.org/wiki/OpenMP

See Also Links

Shouldn't the "See Also" links that lead to an article that does not exist, be removed?

Not necessarily; they might be relevant subjects we're just waiting for someone to write about. Graue 22:58, 22 May 2005 (UTC)

Links to free compilers

I didn't think the "Obtaining a Compiler" section was appropriate; it would make sense in a guide, but not an encyclopedia article. So I was bold in editing pages and moved those links down to a subcategory in the "External links" section, and I removed Dev-C since it's not a compiler, but an IDE based around a compiler already in the list. If anyone feels like making and linking to a "List of C compilers," that might be a better solution. Graue 22:56, 22 May 2005 (UTC)

Static polymorphism with C templates

Anyone care to add some notes on this? descender 01:50, 24 Jun 2005 (UTC)

EC

Should metion go in about the proposed EC standard? --ORBIT 6 July 2005 21:47 (UTC)

Full text of ISO/IEC 14882

Full text of ISO/IEC 14882 wanted, where can find it? I found no such entries in external links in the article. -- Yaohua2000 18:45, 16 July 2005 (UTC)

That's because the standard is not free to obtain. There is old draft copy of the internet you can legally get though. Committee Draft #2 (CD2) of the 1998 C standard List of corridenda (corrections/updates/clarifications) voted into the 2003 standard -- KTC 10:21, 8 September 2005 (UTC)

Technical limitations?

With the most recent upgrade, could this article be moved to C ? john k 07:35, 28 July 2005 (UTC)

Unfortunately woudn't work, HTML escaping applies. Pavel Vozenilek 17:51, 28 July 2005 (UTC)

Now fixed as you can see —Phil | Talk 11:06, 5 January 2006 (UTC)

Moved from the article

An anonymous user replaced the "C is not a superset of C" section with a personal rant against C . While the addition is a blatant NPOV violation and not encyclopedic, I thought it was worth preserving on the talk page as criticism of C . — JIP | Talk 06:44, 30 August 2005 (UTC)

C is not as good as C

C was originally written as a language that was as powerful as assembly but is also portable to other platforms. There is a common realm of thought that if the PDP-11 had supported "XCHG" instructions, we'd see them as operators in C.

C actually evolved from C so those who say "it's another language entirely" are not correct in my opinion. Original C compilers actually generated C code. Infact, C grew from the field as people used C in absurd and obscure ways those obscurities actually made it into the language as standards! No matter how bad the programming methodology was!

This is C 's fatal flaw, being backwards compatible with C. The flexiblity of C, essentially a "macro assembler" which "high level constructs". This doesn't make for good voodoo! As a high level language it provides a more rigid interface and hard to expand model. The implicit operations of C also make it harder to read, harder to maintain and harder to figure out exactly wtf the scope of something is.

They state that C is "OO" however, C can be written as OO as well. OO is not langauge syntax but rather how the design is constructed. Just because you use "class" doesn't automatically make your code, "OO" which is another common mistake. Actually, if you can't understand how to do "OO" in C, you actually shouldn't be writing it in C because you definately don't understand "OO"!!!!!

C has lots of bad things such as pass by reference, operator overloading, multiple inheritence and copy constructors. One of the main goals of an "abstraction" is just that. The user doesn't need to know the details of how it was implemented to use it. Unfortunately, this is not the case with C . You NEED to know how it was implemented in order to use it. For example, is that implicit copy constructor a shallow or deep copy? I better know before I pass anything by value! What the hell does the " " do? By the function name, I really have no idea. Will "-" work on the same data? I'd rather see a function descriptive NAME rather than a or - if it's not a real mathematical operation.

Functions and variables are hard to scope. If you see them in a class you have no idea where they came from. Are they global? Are they in some nth inherited class? How about classes that reuse function names of real functions? Hard to track down what one is being used and you could make mistakes!

What about ease of implementation? Arrays can be dangerous with polymorphism! Typecasting back to a base class and indexing will cause corruption of data!!! AND THIS COMPILES FINE! Now to write a simple array you have to write hundreds of lines of code to do something so simple. So there's trade offs, to do something simple you need to write tons of code!

C is easier to read and understand. There are less keywords to make it simpler to optimize and figure out what's going on. If you consider that people can write bad C code and C includes C and more, then obviously C is a disaster waiting to happen because you have all the bad habits that can occur in C (from a few simple keywords) to everything new that you can do (a ton of complex, hard to read and understand functionalities and implicit operations).

All in all, if you want high level constructs, use a high level language like Java or C#. If you want lower level constructs, use C or assembly if need be. However, never use C !!!!!!!!!

C is ideally suited for computer graphics, since it involves a lot of linear algebra and object oriented modelling, where operator overloading and polymorphic methods are indeed very convenient. The language also yields roughly as fast binaries as C, something which is also very importaint in realtime applications. --Fredrik Orderud 13:55, 8 September 2005 (UTC)

peer review or FAC?

Perhaps someone should try to get this article featured. Java already is :( :) --MarSch 15:30, 27 October 2005 (UTC)

This article needs a LOT of work before it can get there. It is very messy/disorganized and could do with a lot more information added. Nathan J. Yoder 17:33, 27 October 2005 (UTC)

How do you think it should be organized and what info needs to be added? --MarSch 13:16, 28 October 2005 (UTC)

Syntax highlighting

I've added syntax highlighting to the code snippets. They highlighting style is à la "Visual C ", whereby keywords and preprocessor directives are blue (I used "mediumblue" for less visual intrusion) and comments are green. --K3rb 03:56, 25 November 2005 (UTC)

Well, after some contemplation, I've removed all the syntax highlighting. Reasoning: highlighting is useful for experienced programmers, but it may confuse readers unfamiliar with programming into thinking that the color is neccessary element of the code examples. See the C programming language talk page for their motivation to not highlight the C code samples. --K3rb 05:17, 27 November 2005 (UTC)

Added link to GNU Common C

GNU Common C is a portable and highly optimized class framework for writing C applications that need to use threads, sockets, XML parsing, serialization, config files, etc. This framework offers a class foundation that hides platform differences from your C application so that you need not write platform specific code. GNU Common C has been ported to compile nativily on most platforms which support either posix threads, or on Microsoft Windows

C and old-style function declarations?

The article says that this is not valid C :

int subtract(minuend, subtrahend)

int minuend;

int subtrahend;

{

return minuend - subtrahend;

}

Is this true? I'm much more of a C guy than a C guy, but I have used this style of function declaration many times over (it is easier to read when your function has many args) and C compilers have gladly accepted it. Have I been coding outside of the language spec all this time? –Andyluciano 19:09, 31 December 2005 (UTC)

It's not legal. It was removed early in the C process.--Prosfilaes 23:40, 5 January 2006 (UTC)

Yes, thank God. Justforasecond 05:44, 17 January 2006 (UTC)

"Thank God?" I don't understand why so many find this construct so ugly. It is shorter to read, shorter to write. Let's say your function takes many arguments of the same type. Would you rather write:

void myfunc( type a, type b, type c, type d, type e, type f )

and have your declaration be wider than your text editor? Why bother, when you can write:

void myfunc( a, b, c, d, e, f )

type a, b, c, d, e, f;

That saves you from specifying the type so many times (repetitive typing) and makes it so the declaration is visible in your text editor. This would especially make sense in C , where type names are generally longer and class names in method declarations would take up lots of horizontal space. But I guess some programmers aren't interested in diversity of style. – Andyluciano 16:35, 17 January 2006 (UTC)

criticism section?

What would yall think of a criticism section for this article?

Justforasecond 05:45, 17 January 2006 (UTC)

There are so many criticisms of C from so many different points of view, many of them conflicting. If you want to do this I would suggest you consider close to all of them and keep in mind it is a contentious topic and someone will probably disagree with what you write. – Andyluciano 16:51, 17 January 2006 (UTC)

Paradigm

Wouldn't be more accurate to describe C as multiparadigm language instead of 'OO' to help distinguish it from languages like java etc. FlyHigh 19:50, 17 January 2006 (UTC)

I agree. For one, the programming paradigm article specifically cites C as an example. Edited. – Andyluciano 05:20, 20 January 2006 (UTC)

C struct article

It seems there's a new C struct article, which explains member functions, constructors/destructors and operator overloading, with structs rather than classes. Of course, it's more usual to explain classes first, with the note that C 's structs are the same as classes except that members are 'public' by default. Can somebody set them straight, please? I never seem to get anywhere with such disputes. StuartBrady 17:38, 28 January 2006 (UTC)