Talk:C (programming language)/Archive 11

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 5 ← Archive 9 Archive 10 Archive 11 Archive 12 Archive 13 → Archive 15

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. [1] —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. 'FLaRN'(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)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:C_(programming_language)/Archive_11&oldid=1149984399"