Talk:C (programming language)/Archive 5

From Wikipedia, the free encyclopedia

 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 4 Archive 5 Archive 6 →

Contents

C90

C90 redirects here. But "C90" isn't anywhere on this article. Brianjd 09:28, 2004 Nov 29 (UTC)

C90 is an informal term for the C language as described by the 1990 international ISO standard. C89, similarly, describes the ANSI 1989 standard, which is almost identical. They're not mentioned here mainly because they are informal and not totally universal, although the standards are described. Deco 22:11, 15 Dec 2004 (UTC)

large programs

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.

It's a matter of what you mean by "large." C was an important early structural programming language, and structural programming enables the creation of more modular and organized and so larger programs. Its type system also facilitates maintenance of larger programs that are difficult in assembly. Even a program of a few K in code bytes is quite an undertaking in assembly, while something that could be written as a small assembly program really doesn't require a higher-level language like C (assuming porting it isn't a big effort.) Maybe this isn't reflected in the text, but I'm not sure how to word it. Deco 22:06, 15 Dec 2004 (UTC)

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)

far too many external links

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)

I agree, but think some of these should later reappear in articles about "C tools" and so on. Deco 19:28, 10 Feb 2005 (UTC)

Array changes

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)

We've discussed this before, and again I refer you to K&R, which specifically states that C doesn't have multidimensional arrays, but rather arrays of arrays. As for dynamic arrays in C, the reason I keep bringing it up is because my students keep refering to books & articles claim you can't have dynamic arrays in C. If you want to call it something else, that's fine, but I think it is important that people are aware that they can implement dynamic arrays in C. wrp103 (Bill Pringle) - Talk 03:49, 7 Apr 2005 (UTC)
I guess you're right. Semantically, they are arrays of arrays, even if they're not necessarily stored in that manner. I agree with respect to dynamic arrays (let's mention it like we are now but just not use that term). Deco 01:22, 9 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)

Text added to C syntax section

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)

Oy! You removed the comment bit that I'd just rewritten. I agree with your changes b.t.w. -- it should be in syntax, but you coulda checked if it was there first! Never mind, I moved it myself. I still think the main page is far too heavyweight and detailed. Most of the information should be moved to separate articles, with just very brief coverage on the main page. Akihabara 08:22, 18 Apr 2005 (UTC)


C: High, middle, or low-level language

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 want to say "medium"; "low-level" as I've heard it used has a strong connotation of "assembler or machine language", but C is certainly the lowest thing that has been called a high-level language. DanielCristofani 14:10, 17 May 2005 (UTC)
Well, compared to languages that are being designed today, C is relatively low-level, but I think the historical precedent has been to describe C as high-level. In contrast, languages like Python are often called "very-high level languages". In any case I don't think we should use the term "medium-level language", as that is not at all standard usage (googling for "high-level language C" yields more than 5.5 million hits; googling for "medium-level language C" yields fewer than than 35,000). Therefore, given the choice between high- and low-level, I think HLL is a better description of C. Neilc 03:39, 27 May 2005 (UTC)
What would happen if we didn't use any of these phrases (at least prominently near the start of the article)? If they don't have clear, agreed-upon meanings even among people knowledgeable about programming languages, I doubt they're much use to the less-informed readers the article is written for. I'm going to remove the phrase and see if anyone objects. DanielCristofani 04:47, 27 May 2005 (UTC)
A link to medium-level programming language somewhere in the article is necessary, as it describes many important characteristics of C and other C-level languages. It doesn't have to be on the top. The terms high-level and low-level are historically pretty well defined (at least better than some like "object-oriented" or "structured"), and C is a canonical example of neither, but a borderline case. Hence the invention of term "medium-level" (or "portable assembler" / "high-level assembler" etc.). And I didn't know about the 17 May revert when I did the change, no revertwarish intentions here, just a coincidence. Taw 11:55, 27 May 2005 (UTC)
I've just made "low level" and "medium level", down in the first paragraph of "Overview", into links to the appropriate articles. DanielCristofani 03:50, 28 May 2005 (UTC)
C is not "typically" called a "low level language". It is at least a medium-level language (I would still argue it is a high-level language according to historical precedent). Neilc 05:24, 28 May 2005 (UTC)
I've tried to rephrase it; it's a little awkward and maybe the paragraph now needs rewriting but it should probably say the same things it now says and should include all three links... DanielCristofani 10:19, 28 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)

Shoe1127, "high-level" doesn't usually mean that a language is difficult, it means that the languge abstracts away from hardware details. Thus, it is possible for a beginner's language to also be high level -- in fact, BASIC is in a high-level language. Regarding the question of whether C is high-level or low-level or neither, I don't really have anything to add... Cadr 22:52, 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)

The terms "high-level" and "low-level" refer to how similar the langauge is to the hardware. Since C is portable, technically it would have different "levels" in comparison with different architectures. However, since most hardware is very similar, the "level" of C can be said to be about the same for every architecture.
Saying this, it should be noted that the terms "high-level" and "low-level" are NOT precise, exact, OR well defined. Parts of C are high-level, and parts are low-level. Saying that the language is "somewhere between" is NOT accurate, nor does it give a good picture of what C is - which is a mix between low level and high level syntax.
I disagree however that the "level" of a language is a bad way to categorize - but if we do categorize C this way, it should be CLEAR what we mean by it. Fresheneesz 00:50, 3 June 2006 (UTC)


From The C Programming Language by K&R, first edition (I'm old school), page 1:

"C is a relatively 'low level' language."

From Introduction to Computing Systems: From Bits & Gates to C and Beyond by Yale Patt and Sanjay Patel, second edition, pages 293-294:

"C was developed for use in writing compilers and operating systems, and for this reason the language has a low-level bent to it. The language allows the programmer to manipulate data items at a very low level yet still provides the expressiveness and convenience of a high-level language."

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)

Could we just say it's a high-level language as compared to assembly language but low-level as compared to other high-level languages? If a bunch of people knowledgable about C can't make up their minds, it's evident that there's probably not one right answer. Deco 21:38, 19 June 2006 (UTC)
I have always considered it a fairly low-level language. The definition I'm familiar with for a low-level language is that the number of machine language statements generated tends to be less than the same program written in a high-level language. The fact that K&R also considers it a relatively low-level language, I would vote for "relatively low-level language". wrp103 (Bill Pringle) 21:54, 19 June 2006 (UTC)
Hmm, that's a weird definition. Let me throw in a vote for (somewhat) "High Level". C has complex control structures (do, while, for), functions, and a real and powerful type system. At the time it was created, it was high level, about on par with Pascal or Modula 2. Low-level languages are languages that are specific to a processor, high-level languages abstract these details away... --Stephan Schulz 22:07, 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'm kind of with you on that, and everyone else seems to have missed the point :) The problem is a fundemental problem of definition, which this page hasn't addressed yet. The 33 key words define a low level (3G, procedural) language: there aren't even input and output operators. On the other hand, standard C (which includes the standard C libraries), is an ordinary (3G, procedural) language. 218.214.148.10 02:39, 6 November 2006 (UTC)
The 'closeness' to asm or machine code has become a bit of a red herring partly because most people have never examined the machine code generated by Pascal or Fortran compilers, so that's worth clearing up: For most of their lives, Pascal and Fortran compilers generated smaller, faster, tighter code than C compilers, and there was generally a one-to-one correspondance between lines of code and assembler constucts in all three languages. The smaller faster tighter code resulted from better optimisation (tied to the simpler syntax), and better integration of the 'library' functions, not because i++ compiled differently than i=i+1.
On the other hand, sprintf is a high level construct, and that's why C, not Pascal or Fortran, eventually replaced asm as the language of choice for writing Windows Device Drivers. The high level constructs in C are parts of the library that can, with care, be re-written or excluded. Note that it took a while though: Windows NT was written in C, but the Windows NT device drivers were written in asm, because in C it was difficult to get the kind of smaller tighter faster code required. 218.214.148.10 02:39, 6 November 2006 (UTC)
That's mainly because the x86 architecture doesn't provide good support for HLLs including C. Unix device drivers were all written in C on the PDP-11 and VAX, even the interrupt-handling code (except for a small veneer to save "scratch" registers and map into the C functioon interface). On some processors such as M*CORE, there is such a close match that even the interrupt-handler veneer isn't needed. PDP-11 C programmers quickly learned how to code so that they would get the desired object code, e.g. do...while(--i) to get a SOB instruction. The optimizer underwent continual improvements, but for a long time you'd see micromanaged source code like this. Efficiency really mattered on small, slow machines. DAGwyn 21:04, 7 November 2006 (UTC)
Yeah, my final vote is that C is a relatively low-level programming language. If that's good enough for K&R, that's good enough for me. 70.17.41.123 21:02, 21 June 2006 (UTC)
A lot of the confusion comes from a seemingly small distinction. Are "low level" and "high level" two distinct categories of languages, or are they purely relative terms like "tall" and "short"?
Both uses have a long history. When the terms are used to refer to distinct categories, "low level language" means machine language or assembly language--these are processor-specific, and assembly is almost isomorphic to machine language. A "high level language" is then anything that needs a compiler or an interpreter. (If people were going to draw a crisp line, it makes sense that it was placed there, because there is a bit of a gap between assembly and (say) FORTRAN and then a smooth-ish gradation from FORTRAN up through more and more abstract and featureful languages. Also, when the line was drawn, other languages were not vastly more featureful than C, and it was still common for people to write programs in assembly language.) In short, when "low-level" and "high-level" are used as names of discrete categories, C is definitely a "high-level language".
On the other hand, when the terms are used in a purely relative way, C is plainly at a lower level than most other computer languages, and especially it is at a lower level than most other computer languages people write programs in, since assembly-language coding has lost popularity. (Likewise FORTRAN etc.) So it is entirely correct to say that "C is a relatively low-level programming language" or "compared with more recent languages, C is a low-level language". Even "C is a very low-level language" would be better than "C is a low-level language", because the word "very" would make it clear that the phrase was being used as a comparative, whereas in isolation it looks like a classification.
But there are more modern languages that are assembly languages, so "compared with more recent languages" is going down the wrong track. — DAGwyn 09:43, 2 September 2006 (UTC)
In short, yes, "C is a relatively low-level programming language" and "C is a high-level programming language" mean subtly different things and they are both unimpeachably correct. DanielCristofani 21:37, 21 June 2006 (UTC)
One way of rolling both aspects into the same sentence is to say "C is relatively low level as high-level languages go." —Steve Summit (talk) 14:42, 23 June 2006 (UTC)
The categories are sloppy to start with, and there isn't a well-ordering of "levels" for PLs. C is definitely a low-level HLL. Unless something crucially depended on the category, which it doesn't, "relatively low-level" conveys enough of the right flavor: not the lowest level, but also not very far from it. — DAGwyn 09:43, 2 September 2006 (UTC)

Confusing link

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)]

The deleted link was to the book C Unleashed by Heathfield et al. External links to reference materials should be included or deleted based on their relevance and notability, not on their free/paid status. (We've got several other printed, purchasable books listed, all relevant and notable.)
I'm not going to restore the link myself, because I'm one of its contributors and therefore not unbiased, but if anyone else would like to, feel free. (The book's notability is somewhat enhanced in that many of its contributors were comp.lang.c regulars.) Steve Summit (talk) 23:36, 5 February 2006 (UTC)
Agreed. I restored the link to the book. In my opinion, it's not appropriate for an encyclopaedia not to list notable purchasable material solely due to the fact that it's not free. Denis Kasak 15:16, 29 March 2006 (UTC)

Initialization of static variables

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

Because all static data is required to be initialized prior to program startup, and parts of the program cannot be run before it starts. Deco 05:52, 21 February 2006 (UTC)
Well, then how is the same possible in C++, and by the way do you mean to say that memory is allocated for static variables well before the program starts.
Well, C++ is a different language! It's got mechanisms that let initialization code run before main() is called. C doesn't do that. But yes, it's correct to imagine that the memory for static variables is allocated and initialized before main is called. --Steve Summit (talk) 15:55, 21 February 2006 (UTC)
Yeah, C++ needs this to enable constructors of objects of global lifetime to run properly. Deco 18:04, 21 February 2006 (UTC)

D

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)

It's in the right place. Since C has spawned so many imitators and successors, a "Related/Successor languages" section is appropriate. The paragraph on D someone just added is appropriately brief. The C++ discussion just above should probably be condensed. It would probably be worth adding brief paragraphs on other notable successor languages, including Java and maybe Perl and JavaScript. —Steve Summit (talk) 15:10, 10 March 2006 (UTC)
But Objective-C is much closer related to C than D (or even C++) is, still it is not mentioned here... —The preceding unsigned comment was added by 62.178.213.223 (talk • contribs) 23:31, 18 March 2006 (UTC)
Sofixit! :-) —Steve Summit (talk) 01:48, 19 March 2006 (UTC)
agreed - the D paragraph explicitly says it is making a break from C - so why include it here? There are plenty of languages that are just as close to C or closer than D. The paragraph should be removed.
I don't agree. It's useful to have brief mentions of the languages closely related to C. I would include: C++, Objective C, D, Java and maybe C#. The discussion of C++ is too long. It should be about the length of the paragraph on D, with a pointer to the full article. I don't think that "making a clean break" makes a language necessarily more distant. Even though C++ attempts to maintain backwards compatibility with C, in other ways it is more distant from C than is D. In particular, I would say that the lack of multiple inheritance makes D in a significant respect closer to C than C++ is.
The point is that there is a small group of languages conceived by their creators as improvements to C (as opposed to languages of a quite different type), and it is useful mention these and give brief summaries of their relationship to C in the C article. The alternative of just listing pointers to the articles about them is inferior in that those articles will not in general focus on the differences from C. We shouldn't force the person who is mainly interested in C and just wants a little bit of context to have to work through those other articles and figure out the differences himself or herself.Bill 21:02, 9 May 2006 (UTC)
Then I'd list Java, C++, Objective-C, C#, Ch, Cyclone, C-- (there are I think several of these) and D (at least). It's misleading to just put C++ and D.
Indeed, if you look at my first paragraph you'll see that I suggested a longer list.Bill 08:11, 11 May 2006 (UTC)
It all boils down to what "related languages" mean. C++ is given, because it is a direct successor to C basically implementing the entire feature-set, and so is Objective-C, which should have an entry. Unless the rubric read "other curly-bracket languages" (or "languages vaguley remninescent of C in some ways") D shouldn't be featured any more than Java. Especially since the article says that it breaks cleanly with C, which basically only makes it nothing but a curly-bracket language with only superficial similarities with C, just as Java. Mikademus 08:12, 7 July 2006 (UTC)
Edit: I added a section about Onjective-C. Since both C++ and ObjC are supersets of C it makes the D entry even more out of place. Mikademus 08:23, 7 July 2006 (UTC)
Perl is more a successor to AWK than to C, don't you think?Bill 03:15, 19 April 2006 (UTC)

C#

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)

I don't see why we need to discuss C# at all: although it happens to have "C" in its name, it is not all that closely related to C (no more closely related to C than Java is, for example). Since the text was pretty poorly written (I agree with the gist of Alexthe5th's comments), I just removed this section. A section on Objective C would be reasonable, as it is closely related to C -- but I think C# is sufficiently far from C it doesn't deserve a whole subsection. Neilc 03:32, 19 April 2006 (UTC)
I agree. C# procures C's syntax and good name to draw attention, not unlike C++ or Java before it, but its semantics are distinctly dissimilar. Deco 21:20, 17 June 2006 (UTC)

Object code and linking

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)

Good idea. Such an article could/should be written generically, with specific details on specific (i.e. C) languages. Wouter Lievens 12:55, 20 April 2006 (UTC)
Sounds good to me. wrp103 (Bill Pringle) 14:19, 20 April 2006 (UTC)