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 3 | Archive 4 | Archive 5 | Archive 6 | Archive 7 | → | Archive 10 |
C90 redirects here. But "C90" isn't anywhere on this article. Brianjd 09:28, 2004 Nov 29 (UTC)
This is no accident; C was created with one important goal in mind: to make it easier to write large programs with ...
If we mean it's original creation circa 1972, this is certainly not the case. C was at that stage for a machine with max program size 12K, there was no way you could write a large program in C. Rather, C was created so they would have something slightly nicer and more portable than assembler to use on a machine that was too small to fit almost any other language then in existence. Some support for large programs emerged later, but really large programs have never been C's strength. It shines for small to medium sized, fast, close to the metal stuff.
At any rate, I wouldn't say that C was created with "one" goal in mind, and certainly not that "writing large programs" was the primary goal. C, like Unix, was created by programmers for programmers, as a pleasant tool/environment for writing the kinds of programs they wanted to write, using the philosophy they were then exploring and inventing. The most important aspects of that philosophy (again applying to both C and Unix) were probably: minimalism, and freedom from arbitrary limitations or other strictures. Steve Summit 05:24, 13 July 2005 (UTC)
There are far too many external links, some are for rather unimportant programs, almost seems like a bit of advertising or fanfare has slipped in here. I'm taking a bush-whacker to it, but feel free to add anything back that seems critical. Daniel Quinlan 08:39, Feb 10, 2005 (UTC)
For what it's worth, dynamic arrays are not really supported by the C language proper. Arrays whose size are known at runtime can be allocated using the standard library, but these do not have array types — they are assigned to pointer variables and merely treated syntactically in a manner similar to arrays. This is the original reason I originally omitted them. I realise it seems counterintuitive to say C doesn't have dynamic arrays, but really it's something you implement in C, not something C gives you. This is why I've softened the language of this part.
Oh, and multidimensional arrays are not arrays of arrays. This is just syntax — they're laid out in row-major order, and the index is computed using multiplication, not obtained by successive pointer fetching as in a true array of arrays. I've attempted to clarify this. Deco 04:45, 6 Apr 2005 (UTC)
I think there are a lot of areas of overlap between the C language, C syntax, and C standard library articles. I do think that this needs to be resolved.— Kbolino 04:20, Apr 7, 2005 (UTC)
Before anyone complains (or reverts me), I wanted to explain the text I added to the C syntax section — the idea is to provide a supercondensed summary for those who don't want to dive into all the details of the full article. This is a very common thing to do wherever you see a main article note, and I think it's appropriate here, although the summary is necessary technical and missing lots of information. If they need to know more they can visit the main article. Deco 04:11, 18 Apr 2005 (UTC)
Okay, I can see we're seting up for a revert war here with the question of whether C is a high-level language, low-level language, or something in-between.
Personally, I've always thought of C as one step above assembler, so it's a pretty low-level language to me. (It's got no inherent matrix operations, no string operations, no garbage collection, etc. You get to manage memory all by your lonesome self. Pointers are a nearly-direct representation of what PDP-11s and VAX computers do in single machine-language instructions.) And other text in the article supports this assertion. But I'd like to hear what others have to say before changing this again.
Atlant 12:06, 17 May 2005 (UTC)
I think that "levels" in this usage is relative to implementation (with "machine language" being the lowest possible level in any case). For example, if an application is written in C and then directly translated into machine language, then C is the higher level language in this implementation; but if an interpreter for BASIC was written in C, C would be the middle level. I think that defining levels may be meaningless without a context. Mal7798 05:13, 03 June 2006 (UTC)
I certainly wouldn't object to the lede not trying to characterize the "level" of C.
Atlant 11:35, 27 May 2005 (UTC)
The fact is, these "levels" are too ill-defined and inconsistent in their usage to characterize the level of nearly any language, especially one lying near the boundary like C. Better might be to give comparisons; I think we can all agree it's higher-level than assembly, but lower-level than Ada, Smalltalk, Java, or Haskell. Or we might just say, "some call it X because Y" for each one — just don't go on about it in an inappropriate place like the intro paragraph. Deco 09:54, 28 May 2005 (UTC)
It's certainly the case that C is a HLL in the mainstream sense of that term, namely
"something significantly higher and significantly different from,
but that typically compiles down to, assembler."
And it's equally certain that C is very low-level, as high-level languages go.
These points are very well worth mentioning, as is a third:
that referring to C as "high level assembly"
is sometimes done fondly and sometimes pejoritavely
(that is, critics accuse C in this way, but adherents love the language for it).
But the term "medium level" is, I agree, pretty meaningless.
Steve Summit 05:34, 13 July 2005 (UTC)
As to the question of C's "level", I agree that catagorizing the language this way is mostly without warrant. C is, in nearly ever sense of the word, a beginner's language. I believe it to be realtively simple, and only a step above the beloved BASIC dialects. In fact, my first language was C and I believe it to be a valuable learning tool. For this reason, if find it hard to describe C as a "high level" language, yet at the same time I remain partial to it and hope it remains in close memory.-
Shoe1127 22:08, 19 May 2006 (UTC)
I would say c is a medium low level language. I program several languagess and this is what i think thanks Rekh 19:08, 30 May 2006 (UTC)
From The C Programming Language by
K&R, first edition (I'm
old school), page 1:
From Introduction to Computing Systems: From Bits & Gates to C and Beyond by Yale Patt and Sanjay Patel, second edition, pages 293-294:
I think it's best to say that C is a relatively low-level language, as compared to high-level languages. I wouldn't call it medium-level, since there really isn't such a thing. Low-level implies the language keeps the programmer in touch with the machine, high-level implies otherwise. 70.106.101.119 19:25, 19 June 2006 (UTC)
It is a low level language if you look at c key words it is very low there are 33 key words. Everything else is additional functions not neccessary to use. Rekh 18:23, 21 June 2006 (UTC)
i´ve deleted the link because this is not suppose to promote paying books, nevertheless its quality.
if you want to promote a book try other place! or even other sectionin wiki.
[preceding
unsigned comment added 4 February 2006 at 18:54 by
62.169.90.135 (
Talk |
contribs)]
Hi, I recently came across in C that we cannot call functions while initializing static variables in C, why is it so?
int my_function(void); int main() { static int p = my_function(); }
Thanks
Is the paragraph on the D language really necessary in the C article? It seems like a 'See also' link would be enough. -- ozzmosis 12:08, 10 March 2006 (UTC)
Since some feel that programmers are not encouraged to understand the workings behind C# and the way it handles possible "dangerous" computer tasks, they are expected to trust that C# simply works. Some programmers believe that it is not anywhere nearly as stable as C or C++. C# is often compared and contrasted with C and C++. C# runs on the .NET Framework and was developed by Microsoft.
I don't have any bias towards Microsoft or any other software development company, but I've never heard of C#'s "stability" being an issue. Since C# is merely a language, any comments about stability don't make any sense (unless you decide to confuse C# with the .NET Framework, which is the underlying virtual machine). Since the .NET Framework itself has gathered a good reputation for its own speed and stability, I'm not sure where the contributor was trying to go with this. You could probably make a pretty good argument that managed code is actually more stable than native C, especially with garbage collection and the lack of unsafe pointers.
Either way, though, "some programmers" and "some feel" are a great example of weasel words, which I think should be avoided. What are your thoughts? Alexthe5th 11:16, 12 April 2006 (UTC)
This article could do with a cursory reference to other pages describing object code and linking. I think the "Hello World" example gives the misleading impression to a newcomer that the printf
function's implementation is contained in stdio.h, whereas in fact all that is there is a declaration of the function, that is linked later on.
What's not obvious to a C newcomer is the "compiler" is typically a front end that includes the preprocessor, source to object code compiler, and linker, and that a link to the standard library ( eg: libc.a (Unix), libc.lib (Microsoft) ) is automatically implied.
This concept confused me for a while when I first learned C on a DOS platform, as I assumed that somewhere inside the standard library there must be C code that writes characters to the display, whereas in fact that was written in 8086 assembler calling DOS INT 21, using the correct calling convention, and linked in.
I don't think there needs to be much in-depth discussion on the main page as it sets better on another page specifically covering linking architecture, but a cross reference would be useful.
Thoughts?
-- Ritchie333 12:24, 20 April 2006 (UTC)
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 3 | Archive 4 | Archive 5 | Archive 6 | Archive 7 | → | Archive 10 |
C90 redirects here. But "C90" isn't anywhere on this article. Brianjd 09:28, 2004 Nov 29 (UTC)
This is no accident; C was created with one important goal in mind: to make it easier to write large programs with ...
If we mean it's original creation circa 1972, this is certainly not the case. C was at that stage for a machine with max program size 12K, there was no way you could write a large program in C. Rather, C was created so they would have something slightly nicer and more portable than assembler to use on a machine that was too small to fit almost any other language then in existence. Some support for large programs emerged later, but really large programs have never been C's strength. It shines for small to medium sized, fast, close to the metal stuff.
At any rate, I wouldn't say that C was created with "one" goal in mind, and certainly not that "writing large programs" was the primary goal. C, like Unix, was created by programmers for programmers, as a pleasant tool/environment for writing the kinds of programs they wanted to write, using the philosophy they were then exploring and inventing. The most important aspects of that philosophy (again applying to both C and Unix) were probably: minimalism, and freedom from arbitrary limitations or other strictures. Steve Summit 05:24, 13 July 2005 (UTC)
There are far too many external links, some are for rather unimportant programs, almost seems like a bit of advertising or fanfare has slipped in here. I'm taking a bush-whacker to it, but feel free to add anything back that seems critical. Daniel Quinlan 08:39, Feb 10, 2005 (UTC)
For what it's worth, dynamic arrays are not really supported by the C language proper. Arrays whose size are known at runtime can be allocated using the standard library, but these do not have array types — they are assigned to pointer variables and merely treated syntactically in a manner similar to arrays. This is the original reason I originally omitted them. I realise it seems counterintuitive to say C doesn't have dynamic arrays, but really it's something you implement in C, not something C gives you. This is why I've softened the language of this part.
Oh, and multidimensional arrays are not arrays of arrays. This is just syntax — they're laid out in row-major order, and the index is computed using multiplication, not obtained by successive pointer fetching as in a true array of arrays. I've attempted to clarify this. Deco 04:45, 6 Apr 2005 (UTC)
I think there are a lot of areas of overlap between the C language, C syntax, and C standard library articles. I do think that this needs to be resolved.— Kbolino 04:20, Apr 7, 2005 (UTC)
Before anyone complains (or reverts me), I wanted to explain the text I added to the C syntax section — the idea is to provide a supercondensed summary for those who don't want to dive into all the details of the full article. This is a very common thing to do wherever you see a main article note, and I think it's appropriate here, although the summary is necessary technical and missing lots of information. If they need to know more they can visit the main article. Deco 04:11, 18 Apr 2005 (UTC)
Okay, I can see we're seting up for a revert war here with the question of whether C is a high-level language, low-level language, or something in-between.
Personally, I've always thought of C as one step above assembler, so it's a pretty low-level language to me. (It's got no inherent matrix operations, no string operations, no garbage collection, etc. You get to manage memory all by your lonesome self. Pointers are a nearly-direct representation of what PDP-11s and VAX computers do in single machine-language instructions.) And other text in the article supports this assertion. But I'd like to hear what others have to say before changing this again.
Atlant 12:06, 17 May 2005 (UTC)
I think that "levels" in this usage is relative to implementation (with "machine language" being the lowest possible level in any case). For example, if an application is written in C and then directly translated into machine language, then C is the higher level language in this implementation; but if an interpreter for BASIC was written in C, C would be the middle level. I think that defining levels may be meaningless without a context. Mal7798 05:13, 03 June 2006 (UTC)
I certainly wouldn't object to the lede not trying to characterize the "level" of C.
Atlant 11:35, 27 May 2005 (UTC)
The fact is, these "levels" are too ill-defined and inconsistent in their usage to characterize the level of nearly any language, especially one lying near the boundary like C. Better might be to give comparisons; I think we can all agree it's higher-level than assembly, but lower-level than Ada, Smalltalk, Java, or Haskell. Or we might just say, "some call it X because Y" for each one — just don't go on about it in an inappropriate place like the intro paragraph. Deco 09:54, 28 May 2005 (UTC)
It's certainly the case that C is a HLL in the mainstream sense of that term, namely
"something significantly higher and significantly different from,
but that typically compiles down to, assembler."
And it's equally certain that C is very low-level, as high-level languages go.
These points are very well worth mentioning, as is a third:
that referring to C as "high level assembly"
is sometimes done fondly and sometimes pejoritavely
(that is, critics accuse C in this way, but adherents love the language for it).
But the term "medium level" is, I agree, pretty meaningless.
Steve Summit 05:34, 13 July 2005 (UTC)
As to the question of C's "level", I agree that catagorizing the language this way is mostly without warrant. C is, in nearly ever sense of the word, a beginner's language. I believe it to be realtively simple, and only a step above the beloved BASIC dialects. In fact, my first language was C and I believe it to be a valuable learning tool. For this reason, if find it hard to describe C as a "high level" language, yet at the same time I remain partial to it and hope it remains in close memory.-
Shoe1127 22:08, 19 May 2006 (UTC)
I would say c is a medium low level language. I program several languagess and this is what i think thanks Rekh 19:08, 30 May 2006 (UTC)
From The C Programming Language by
K&R, first edition (I'm
old school), page 1:
From Introduction to Computing Systems: From Bits & Gates to C and Beyond by Yale Patt and Sanjay Patel, second edition, pages 293-294:
I think it's best to say that C is a relatively low-level language, as compared to high-level languages. I wouldn't call it medium-level, since there really isn't such a thing. Low-level implies the language keeps the programmer in touch with the machine, high-level implies otherwise. 70.106.101.119 19:25, 19 June 2006 (UTC)
It is a low level language if you look at c key words it is very low there are 33 key words. Everything else is additional functions not neccessary to use. Rekh 18:23, 21 June 2006 (UTC)
i´ve deleted the link because this is not suppose to promote paying books, nevertheless its quality.
if you want to promote a book try other place! or even other sectionin wiki.
[preceding
unsigned comment added 4 February 2006 at 18:54 by
62.169.90.135 (
Talk |
contribs)]
Hi, I recently came across in C that we cannot call functions while initializing static variables in C, why is it so?
int my_function(void); int main() { static int p = my_function(); }
Thanks
Is the paragraph on the D language really necessary in the C article? It seems like a 'See also' link would be enough. -- ozzmosis 12:08, 10 March 2006 (UTC)
Since some feel that programmers are not encouraged to understand the workings behind C# and the way it handles possible "dangerous" computer tasks, they are expected to trust that C# simply works. Some programmers believe that it is not anywhere nearly as stable as C or C++. C# is often compared and contrasted with C and C++. C# runs on the .NET Framework and was developed by Microsoft.
I don't have any bias towards Microsoft or any other software development company, but I've never heard of C#'s "stability" being an issue. Since C# is merely a language, any comments about stability don't make any sense (unless you decide to confuse C# with the .NET Framework, which is the underlying virtual machine). Since the .NET Framework itself has gathered a good reputation for its own speed and stability, I'm not sure where the contributor was trying to go with this. You could probably make a pretty good argument that managed code is actually more stable than native C, especially with garbage collection and the lack of unsafe pointers.
Either way, though, "some programmers" and "some feel" are a great example of weasel words, which I think should be avoided. What are your thoughts? Alexthe5th 11:16, 12 April 2006 (UTC)
This article could do with a cursory reference to other pages describing object code and linking. I think the "Hello World" example gives the misleading impression to a newcomer that the printf
function's implementation is contained in stdio.h, whereas in fact all that is there is a declaration of the function, that is linked later on.
What's not obvious to a C newcomer is the "compiler" is typically a front end that includes the preprocessor, source to object code compiler, and linker, and that a link to the standard library ( eg: libc.a (Unix), libc.lib (Microsoft) ) is automatically implied.
This concept confused me for a while when I first learned C on a DOS platform, as I assumed that somewhere inside the standard library there must be C code that writes characters to the display, whereas in fact that was written in 8086 assembler calling DOS INT 21, using the correct calling convention, and linked in.
I don't think there needs to be much in-depth discussion on the main page as it sets better on another page specifically covering linking architecture, but a cross reference would be useful.
Thoughts?
-- Ritchie333 12:24, 20 April 2006 (UTC)