Content deleted Content added
MiszaBot I (talk | contribs) m Robot: Archiving 14 threads from Talk:C (programming language). (ARCHIVE FULL) |
m Bot: Fixing lint errors, replacing obsolete HTML tags: <tt> (6x) Tag: Fixed lint errors |
||
| (3 intermediate revisions by 2 users not shown) | |||
Line 12:
:::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;
Line 18:
float* q = p;
b = *q;
</syntaxhighlight>
:::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: [http://stackoverflow.com/questions/430182/is-c-strongly-typed Is C strongly typed?]. [[User:Adrianwn|Adrianwn]] ([[User talk: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 <
== websites can also be programmed in C ==
Line 43:
'''begin removed text'''<br/>
To this day, Boolean values are commonly represented by integers in C programs. The comparison operators ('<code> > </code>', '<code>==</code>', etc.) are defined to return a signed integer (<code>int</code>) 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"); }
</syntaxhighlight>
is equivalent to
<
int t;
if (x > y) { t = -1; }
Line 55:
if (t != 0) { printf("True!\n"); }
else { printf("False!\n"); }
</syntaxhighlight>
However, since the C language standards allow the result of a comparison to be any non-zero value, the statement <code>if(t==1){...}</code> is not equivalent to <code>if(t){...}</code> or to <code>if(t!=0){...}</code>.
Line 62:
For convenience, many programmers and [[C header file]]s use C's [[typedef]] facility to define a Boolean type (which may be named <code>Boolean</code>, <code>boolean</code>, <code>bool</code>, etc.). The Boolean type may be just an alias for a numeric type like <code>int</code> or <code>char</code>. In that case, programmers often define also [[C preprocessor|macros]] for the true and false values. For example,
<
typedef int bool;
#define FALSE 0
Line 70:
...
if (f) { ... }
</syntaxhighlight>
The defined values of the <code>TRUE</code> and <code>FALSE</code> macros must be adequate for the chosen Boolean type. Note that, on the now common [[two's complement]] computer architectures, the signed value <code>-1</code> is converted to a non-zero value (<code>~0</code>, the bit-wise complement of zero) when [[type casting|cast]] to an unsigned type, or assigned to an unsigned variable.
Another common choice is to define the Boolean type as an [[enumerated type]] (<code>enum</code>) 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;
...
Line 80:
...
if (b) { ... }
</syntaxhighlight>
Again, since a true result may be any non-zero value, the tests <code>if(t==TRUE){...}</code> and <code>if(t)</code>, which are equivalent in other languages, are not equivalent in C.
Line 100:
Original:
<
printf("hello, world\n");
</syntaxhighlight>
Modify to:
<
printf("%s", "hello, world\n");
</syntaxhighlight>
The '''"%s"''' must be included to avoid a [[Format string attack]]. Please, discuss... [[Special:Contributions/83.55.41.191|83.55.41.191]] ([[User talk:83.55.41.191|talk]]) 21:38, 1 January 2010 (UTC)
:After reading that article and a cursory glance at [http://julianor.tripod.com/bc/formatstring-1.2.pdf this], I believe the vulnerability is present only when you pass "unfiltered user input" directly to these functions as format strings, as in <
: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. [[User:Johnuniq|Johnuniq]] ([[User talk:Johnuniq|talk]]) 03:54, 2 January 2010 (UTC)
Line 132:
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"! [[User:WHPratt|WHPratt]] ([[User talk:WHPratt|talk]]) 19:00, 29 December 2009 (UTC)
:Yes. While it's somewhat common in some circles to see expressions such as <
::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. — [[User:DAGwyn|DAGwyn]] ([[User talk:DAGwyn|talk]]) 02:38, 13 May 2010 (UTC)
Line 149:
Why do people prefer <code>lang="text"</code> instead of <code>lang="c"</code>? [[User:ThePCKid|ThePCKid]] ([[User talk: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... --[[User:Cybercobra|<b
:: I like the highlighting... <nowiki>~</nowiki>[[User:ThePCKid|ThePCKid]] ([[User talk: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. --[[User:Cybercobra|<b
:::: [http://en.wikipedia.org/wiki/Talk:C_(programming_language)#why_not_lang.3D.22c.22.3F Discussion higher up on the page] - [[User:Richfife|Richfife]] ([[User talk: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. — [[User:DAGwyn|DAGwyn]] ([[User talk:DAGwyn|talk]]) 02:57, 13 May 2010 (UTC)
::But it's an extremely useful and widely used crutch. --[[User:Cybercobra|<b
:::My 2¢ worth: Minimalism ([[KISS principle|KISS]]): Keywords should be bold and/or colored, comments should be italic, and everything else should be normal text. For example:
Line 237:
== "Hello world" example using puts() instead? ==
I think it makes more sense to use the <code>puts</code> function instead of <code>printf</code>, as the "\n" is not necessary. I have seen <code>printf</code> used in every example I can remember, however. Edit it if you think it's a good idea though. [[User:Flarn2005|'<
: "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. - [[User:Richfife|Richfife]] ([[User talk:Richfife|talk]]) 05:22, 28 July 2010 (UTC)
== Syntax highlighting in the examples ==
Line 244:
: 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. –[[User:Henning Makholm|Henning Makholm]] ([[User talk:Henning Makholm|talk]]) 22:29, 12 October 2010 (UTC)
::{{ec}}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. --[[User:Cybercobra|<b
::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. [[User:1exec1|1exec1]] ([[User talk: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). [[User:Johnuniq|Johnuniq]] ([[User talk: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 [[WP:VOTE|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();
Line 265:
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. – [[User:Adrianwn|Adrian Willenbücher]] ([[User talk:Adrianwn|talk]]) 06:33, 13 October 2010 (UTC)
Line 272:
::::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();
Line 288:
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:
<
:::::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? – [[User:Adrianwn|Adrian Willenbücher]] ([[User talk:Adrianwn|talk]]) 14:16, 13 October 2010 (UTC)
Line 296:
:::::: (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. –[[User:Henning Makholm|Henning Makholm]] ([[User talk: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. --[[User:Cybercobra|<b
:::::::: 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. –[[User:Henning Makholm|Henning Makholm]] ([[User talk: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. --[[User:Cybercobra|<b
:::::::::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. – [[User:Adrianwn|Adrian Willenbücher]] ([[User talk:Adrianwn|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. - [[User:Richfife|Richfife]] ([[User talk:Richfife|talk]]) 18:02, 13 October 2010 (UTC)
:+1 on using syntax highlighting ''like every other popular programming language article''. --[[User:Cybercobra|<b
:+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. —[[User:Chaos5023|chaos5023]] ([[User talk:Chaos5023|talk]]) 21:37, 29 October 2010 (UTC)
Line 314:
:::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? --[[User:Born2cycle|Born2cycle]] ([[User talk: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. --[[User:Cybercobra|<b
::::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. [[User:Rwessel|Rwessel]] ([[User talk:Rwessel|talk]]) 06:08, 5 November 2010 (UTC)
| |||