This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 | → | Archive 5 |
"method" is an unusual word to use for C functions.
"The main
method is required in all C programs that are intended to be executed, but it is not necessary for those that are not so intended." sounds like a joke; in fact, AFAIK the difference between a "C program" and a bunch of C code that's not a "program" is precisely the presence of main. Even if I'm wrong and the sentence is perfectly correct, I don't think that sentence will help readers of this article.
Dereferencing a pointer does not change what that pointer refers to, but produces a new value which is distinct from the pointer's value, and which refers to the data at the address stored in the pointer. But that's too long-winded for the article; I think my new phrasing is okay.
The fact that void pointers exist does not "indicate" that they point to an object of unknown type; the fact that they are CALLED 'void pointers' does, but again that's too long to say and it can be finessed with a rephrase.
I fixed a few grammatical errors too.
DanielCristofani 14:10, 17 May 2005 (UTC)
A recent editor reverted out an addition of mine, stating:
(My addition was (Many modern C compilers can also ignore the //
comment delimiter used by C++ code, although doing so may require a command-line qualifier.)
I'm always amused whenever anyone suggests that all somethings do something or no somethings do something; such a statement is usually wrong. And it's certainly wrong in this case: There's no doubt that the class of C compilers also includes the compilers that implemented only the Old Testament and not just the ANSI standard, and those Old Testament compilers most assuredly do not implement that "https://" comment delimiter. So the "modern" part of my comment was absolutely correct. And the portion about requiring a command-line qualifier was also correct; reasonably-recent and definitely ANSI-compliant versions of the Sun Workshop compilers most-assuredly DO require such a qualifier, although GCC doesn't.
And, of course, my comment was inserted directly after the explanation of "/* */"-style comments, so it was in a relevant context.
So I'm putting it back (although correcting my language as I do so). And if someone wants to go out on the limb and change it from "Many modern C compilers" to "All modern C compilers", more power to you. But you'd better be sure you've inspected all modern C compilers including some rather obscure ones!
Atlant 23:48, 17 May 2005 (UTC)
"remember, C is entirely the work of Dennis Ritchie, I am but a popularizer." (Kernighan in an interview)
Which raises the question: should we say it was "developed" by Thompson and Ritchie? What was Thompson's involvement apart from contributing the B language that C was based on? Maybe it needs a further rephrase...
DanielCristofani 23:31, 6 Jun 2005 (UTC)
I disagree with the list of features C does not have - in that C supports Metaprogramming.
In the article on Metaprogramming, listed as an example of Metaprogramming, is the 'Quine' - "a special kind of metaprogram that has its own source as its output". There are plenty of Quines in the C language. Here's an example:
char*f="char*f=%c%s%c;main(){printf(f,34,f,34,10);}%c";main(){printf(f,34,f,34,10);}
Therefore, by at least this one example, C supports Metaprogramming. Many more are likely to be found as entries for the IOCCC.
Ben-Arba 07:08, Jun 18, 2005 (UTC)
But do we have to be in the agreement whether C supports metaprogramming or not? Aside from the difficulty pointed out above, answering this question sounds rather original research. So I think we'd be better off if we simply list features of C and put some example like Ben-Arba gave in the article and let readers decide. -- Taku 06:35, Jun 19, 2005 (UTC)
Since the watchers of this page evidently have interest in C, I thought some of you might be interested in commenting on the deletion vote Wikipedia:Votes for deletion/C Programming Mistakes for the article C Programming Mistakes. Deco 21:43, 14 July 2005 (UTC)
I removed this comment from the Problems with C section:
This is true for some such checks, but others are made undecidable by the lack of limitations on the language. This comment misleadingly suggests that all problems with C can be overcome by a sufficiently intelligent tertiary static checking tool, which is false, and that Lint is this tool, which is even more false. Deco 01:28, 15 July 2005 (UTC)
Perhaps, this evolved out of a need for optimization? It is often possible to write a complex boolean expression as a binary expression, thereby removing the need for several condition checks and jumps, leading to more compact and faster code.
This is particularly useful in compiler scheduled VLIW architectures, although VLIW may not have been the reason for this
-- User:Gauthamg123 04:49, 18 July 2005 (according to edit history)
While syntax readability is necessarily a subjective matter, I'm afraid I must disagree with singling out the ternary conditional operator ?: as a bad example. In many functional languages such as Lisp and ML, this is the only type of conditional available (usually with a somewhat difference syntax), and it can often greatly reduce redundancy. The problem is that C programmers are unfamiliar with it and don't format code that uses it in a readable way. For example, here's some imperative code:
if (x > a) { if (y > b) { z = x + y; } else { z = x - y; } } else { if (y > b) { z = -x + y; } else { z = -x - y; } }
Now if we write this on one line with ?:, the result is fairly horrific:
z = (x > a ? (y > b ? x + y : x - y) : (y > b ? -x + y : -x - y));
If we format it a bit differently, however, it's really surprisingly similar to the original code:
z = (x > a ? (y > b ? x + y : x - y ) : (y > b ? -x + y : -x - y ) );
Punctuation is still uglier than words, but anyone could read this. In short, I think the lack of readability of this operator arises more out of conventional formatting of C than a language problem. Deco 07:22, 2 August 2005 (UTC)
(x>a?x:-x)+(y>b?y:-y)
--
68.58.69.117 18:24, 3 January 2006 (UTC) (
Random832, not logged in))For the unnamed user editing the intermediate language section, why not go ahead and try rewording the first sentence or two in the section as well. Perhaps break the sentences up a little more and rewording phrases like "which then outputs finished object or machine code". Laundrypowder 20:44, 16 August 2005 (UTC)
The reasoning behind current Visual Studio C99 support might as well be added. As seen on this transcripts http://msdn.microsoft.com/chats/transcripts/vstudio/vstudio_022703.aspx:
Q: Follow-up on the C99 "varargs" question, what, if anything, from C99 will we see in the future from VC
A: In general, we have seen little demand for many C99 features. Some features have more demand than others, and we will consider them in future releases provided they are compatible with C++. It is more likely we'll entertain C99 features if they are picked up in the next version of the C++ standard.
The phrase on their compilers could be worded a little more informatively as they consider new Visual C++ versions really only a c++ compiler. Laundrypowder 14:37, 25 August 2005 (UTC)
A lot of security holes result in the wrong usage of printf to output strings. Why the hell would someone believe
printf (some_string);
to be useful code, if not for all the misleading example code, which demonstrates that printf outputs strings.
An example should use functions in the way that they are meant to be used. Examples should not just happen to work for that special case.
Therefore I argue that
printf ("hello, world\n");
is to be replaced by
puts ("hello, world");
or
printf ("%s", "hello, world\n");
--
Hokanomono 15:40, 21 September 2005 (UTC)
Someone has been adding a number of "Notes" to the article. While they seem well-intended, they are somewhat unclear and at least partially incorrect. I also think they don't belong into an encyclopedia as such - any useful information should go into the main text. I tend towards just removing most of them - any opinions? Here are mine:
-- Stephan Schulz 21:34, 27 September 2005 (UTC)
The C standard document on http://www.nirvani.net/docs/ansi_c.pdf may constitute unlicensed distribution of a copyrighted work. This document must typically be obtained from ISO for 340 CHF (quite a lot of money if you think about it) and under a restrictive license. It may be a freely licensed pre-standard document, too, but I have removed the link for now since it's better to err on the safe side. Aragorn2 19:19, 22 November 2005 (UTC)
"This line terminates the execution of the main function and causes it to return the integral value 0." Isn't it an integer, and not an integral that is returned? I'm not a nativ english speaker, but in norwegian an integral is a diffrent mathematical method (reversed derivation). I'm changing it so change it back if it's wrong ...
I just made several significant changes to the Types section. Since the old text had been there for a while (and presumably accepted), I'd probably better explain my changes here, in case anyone has questions:
Steve Summit ( talk) 02:32, 11 December 2005 (UTC)
As far as I know, functions such as calloc, realloc also count. So, I changed the line
blocks of memory of any desired size can be requested at run-time using the library function malloc()
to
blocks of memory of any desired size can be requested at run-time using library functions such as malloc()
This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 | → | Archive 5 |
"method" is an unusual word to use for C functions.
"The main
method is required in all C programs that are intended to be executed, but it is not necessary for those that are not so intended." sounds like a joke; in fact, AFAIK the difference between a "C program" and a bunch of C code that's not a "program" is precisely the presence of main. Even if I'm wrong and the sentence is perfectly correct, I don't think that sentence will help readers of this article.
Dereferencing a pointer does not change what that pointer refers to, but produces a new value which is distinct from the pointer's value, and which refers to the data at the address stored in the pointer. But that's too long-winded for the article; I think my new phrasing is okay.
The fact that void pointers exist does not "indicate" that they point to an object of unknown type; the fact that they are CALLED 'void pointers' does, but again that's too long to say and it can be finessed with a rephrase.
I fixed a few grammatical errors too.
DanielCristofani 14:10, 17 May 2005 (UTC)
A recent editor reverted out an addition of mine, stating:
(My addition was (Many modern C compilers can also ignore the //
comment delimiter used by C++ code, although doing so may require a command-line qualifier.)
I'm always amused whenever anyone suggests that all somethings do something or no somethings do something; such a statement is usually wrong. And it's certainly wrong in this case: There's no doubt that the class of C compilers also includes the compilers that implemented only the Old Testament and not just the ANSI standard, and those Old Testament compilers most assuredly do not implement that "https://" comment delimiter. So the "modern" part of my comment was absolutely correct. And the portion about requiring a command-line qualifier was also correct; reasonably-recent and definitely ANSI-compliant versions of the Sun Workshop compilers most-assuredly DO require such a qualifier, although GCC doesn't.
And, of course, my comment was inserted directly after the explanation of "/* */"-style comments, so it was in a relevant context.
So I'm putting it back (although correcting my language as I do so). And if someone wants to go out on the limb and change it from "Many modern C compilers" to "All modern C compilers", more power to you. But you'd better be sure you've inspected all modern C compilers including some rather obscure ones!
Atlant 23:48, 17 May 2005 (UTC)
"remember, C is entirely the work of Dennis Ritchie, I am but a popularizer." (Kernighan in an interview)
Which raises the question: should we say it was "developed" by Thompson and Ritchie? What was Thompson's involvement apart from contributing the B language that C was based on? Maybe it needs a further rephrase...
DanielCristofani 23:31, 6 Jun 2005 (UTC)
I disagree with the list of features C does not have - in that C supports Metaprogramming.
In the article on Metaprogramming, listed as an example of Metaprogramming, is the 'Quine' - "a special kind of metaprogram that has its own source as its output". There are plenty of Quines in the C language. Here's an example:
char*f="char*f=%c%s%c;main(){printf(f,34,f,34,10);}%c";main(){printf(f,34,f,34,10);}
Therefore, by at least this one example, C supports Metaprogramming. Many more are likely to be found as entries for the IOCCC.
Ben-Arba 07:08, Jun 18, 2005 (UTC)
But do we have to be in the agreement whether C supports metaprogramming or not? Aside from the difficulty pointed out above, answering this question sounds rather original research. So I think we'd be better off if we simply list features of C and put some example like Ben-Arba gave in the article and let readers decide. -- Taku 06:35, Jun 19, 2005 (UTC)
Since the watchers of this page evidently have interest in C, I thought some of you might be interested in commenting on the deletion vote Wikipedia:Votes for deletion/C Programming Mistakes for the article C Programming Mistakes. Deco 21:43, 14 July 2005 (UTC)
I removed this comment from the Problems with C section:
This is true for some such checks, but others are made undecidable by the lack of limitations on the language. This comment misleadingly suggests that all problems with C can be overcome by a sufficiently intelligent tertiary static checking tool, which is false, and that Lint is this tool, which is even more false. Deco 01:28, 15 July 2005 (UTC)
Perhaps, this evolved out of a need for optimization? It is often possible to write a complex boolean expression as a binary expression, thereby removing the need for several condition checks and jumps, leading to more compact and faster code.
This is particularly useful in compiler scheduled VLIW architectures, although VLIW may not have been the reason for this
-- User:Gauthamg123 04:49, 18 July 2005 (according to edit history)
While syntax readability is necessarily a subjective matter, I'm afraid I must disagree with singling out the ternary conditional operator ?: as a bad example. In many functional languages such as Lisp and ML, this is the only type of conditional available (usually with a somewhat difference syntax), and it can often greatly reduce redundancy. The problem is that C programmers are unfamiliar with it and don't format code that uses it in a readable way. For example, here's some imperative code:
if (x > a) { if (y > b) { z = x + y; } else { z = x - y; } } else { if (y > b) { z = -x + y; } else { z = -x - y; } }
Now if we write this on one line with ?:, the result is fairly horrific:
z = (x > a ? (y > b ? x + y : x - y) : (y > b ? -x + y : -x - y));
If we format it a bit differently, however, it's really surprisingly similar to the original code:
z = (x > a ? (y > b ? x + y : x - y ) : (y > b ? -x + y : -x - y ) );
Punctuation is still uglier than words, but anyone could read this. In short, I think the lack of readability of this operator arises more out of conventional formatting of C than a language problem. Deco 07:22, 2 August 2005 (UTC)
(x>a?x:-x)+(y>b?y:-y)
--
68.58.69.117 18:24, 3 January 2006 (UTC) (
Random832, not logged in))For the unnamed user editing the intermediate language section, why not go ahead and try rewording the first sentence or two in the section as well. Perhaps break the sentences up a little more and rewording phrases like "which then outputs finished object or machine code". Laundrypowder 20:44, 16 August 2005 (UTC)
The reasoning behind current Visual Studio C99 support might as well be added. As seen on this transcripts http://msdn.microsoft.com/chats/transcripts/vstudio/vstudio_022703.aspx:
Q: Follow-up on the C99 "varargs" question, what, if anything, from C99 will we see in the future from VC
A: In general, we have seen little demand for many C99 features. Some features have more demand than others, and we will consider them in future releases provided they are compatible with C++. It is more likely we'll entertain C99 features if they are picked up in the next version of the C++ standard.
The phrase on their compilers could be worded a little more informatively as they consider new Visual C++ versions really only a c++ compiler. Laundrypowder 14:37, 25 August 2005 (UTC)
A lot of security holes result in the wrong usage of printf to output strings. Why the hell would someone believe
printf (some_string);
to be useful code, if not for all the misleading example code, which demonstrates that printf outputs strings.
An example should use functions in the way that they are meant to be used. Examples should not just happen to work for that special case.
Therefore I argue that
printf ("hello, world\n");
is to be replaced by
puts ("hello, world");
or
printf ("%s", "hello, world\n");
--
Hokanomono 15:40, 21 September 2005 (UTC)
Someone has been adding a number of "Notes" to the article. While they seem well-intended, they are somewhat unclear and at least partially incorrect. I also think they don't belong into an encyclopedia as such - any useful information should go into the main text. I tend towards just removing most of them - any opinions? Here are mine:
-- Stephan Schulz 21:34, 27 September 2005 (UTC)
The C standard document on http://www.nirvani.net/docs/ansi_c.pdf may constitute unlicensed distribution of a copyrighted work. This document must typically be obtained from ISO for 340 CHF (quite a lot of money if you think about it) and under a restrictive license. It may be a freely licensed pre-standard document, too, but I have removed the link for now since it's better to err on the safe side. Aragorn2 19:19, 22 November 2005 (UTC)
"This line terminates the execution of the main function and causes it to return the integral value 0." Isn't it an integer, and not an integral that is returned? I'm not a nativ english speaker, but in norwegian an integral is a diffrent mathematical method (reversed derivation). I'm changing it so change it back if it's wrong ...
I just made several significant changes to the Types section. Since the old text had been there for a while (and presumably accepted), I'd probably better explain my changes here, in case anyone has questions:
Steve Summit ( talk) 02:32, 11 December 2005 (UTC)
As far as I know, functions such as calloc, realloc also count. So, I changed the line
blocks of memory of any desired size can be requested at run-time using the library function malloc()
to
blocks of memory of any desired size can be requested at run-time using library functions such as malloc()