Talk:C (programming language)

first comments

hi, it is ritchie and kernigan who developed it, Bjarne Stroustroup did create a subset now called C++. Robert Tito | Talk 11:45, 23 February 2007 (CST)

C++ is not a subset of C. It is (at least mostly) a superset of C89. C99 has new features that are in part taken back from C++ and in part new to C and not (yet) included in C++. Phil Howard 10:48, 24 February 2007 (CST)

Thanks, adding right now.

Is C low-level? AFAIK, it is a mid-level language. --Rion 18:22, 23 February 2007 (CST)

In terms of language feature and design, C could rightly be considered a mid-level language. However (and this is my opinion), it should today be more classified at a lower level, perhaps called "bottom of mid-level or top of low-level". The reason I hold this opinion about C is because more and more of higher level programming that in years (or decades) past might have been done in C are now being done in other languages at a higher level, such as Python. Phil Howard 11:06, 24 February 2007 (CST)

Is it ok, if C will be one of the branches of programming languages? as well as any other progr. lang of course. It will unite every language we can come up with for computers. If you like it, add your name as one of the authors please. Robert Tito | Talk 14:34, 24 February 2007 (CST)

A standard programming language

Could we find a better term than the "is considered a standard programming language" mentioned in the article? Or we need to write an own article what a "standard programming language" is. Except for the fact that C was standardized (which is seemingly not meant as then the "is considered" would be wrong) I think that such a classification is a bit subjective and especially runs the danger of becoming obsolete with time.

There might be also another statement which might be a bit out-dated: "it is the most commonly used programming language for writing system software, though it is also widely used for writing applications". I don't known about system software but is C really still widely used for writing applications? I would have thought it being mostly replaced by OOPL and scripting languages for that by now.

--Markus Baumeister 17:36, 25 February 2007 (CST)

standard?

so far many middleware solutions are build using C, sometimes lending some C++ classing hierarchies. Main reason: it needs being able to talk to EPCDIC-datastructures as well as on the front end to browser based interfases. C is easy to combine with assembler as well as java (and interfases with the majority of the scrintings languages as php/perl etc). contrary to common believe visual studio is not as popular as m$ might want us to believe. Even in redmont for times they used codewarrior in stead of VS to develop new versions of software, specially since the introduction of VS6 and .NET studio. In that period m$-MAC BU developed their solutions solely using codewarrior. Now they cross compile using Xcode as well as GCC. Robert Tito | Talk

GNOME + OSes

Well, most of the GNOME software is written in C. We should maybe note that its derivates are more popular in software writing (C# for Microsoft, ObjC for OS X, C++ for Haiku and so on...) --Rion 07:48, 26 February 2007 (CST)

What's up with the "Vista"? What's the point of inclusion? --Rion 12:57, 2 March 2007 (CST)

if windows is a name, so is vista Robert Tito | Talk 13:29, 2 March 2007 (CST)

But it says Linux, Mac OS X and Windows in general, I mean, XP, 2k et al use derivatives of C too. --Rion 13:47, 2 March 2007 (CST) FYI, GNOME is an open source project (sourceforge) using GCC 3.2 and higher. The same applies for GIMP. C is indeed a low to high level programming language due to its resemblance to assembler and its bit oriented programming capacities - many have been forgotten by all in one solutions like studio and xcode. Robert Tito | Talk 14:14, 2 March 2007 (CST)

Syntax example

Here's my suggestion for a somewhat more complex example in the Syntax section. What do you think about it?

#include <stdio.h>	

int main() {
   int age;
  
   printf("Please enter your age: ");
   scanf("%d", &age);
      if(age < 18) {
        printf("You are not an adult.\n");
      }
      else if(age > 18) {
        printf("You are an adult.\n");
      }
   return 0;
}

Something about Unix

Something could be said in the "history of C" that it was basically developed at the same time as Unix... B was around, then C was developed, then Unix was rewritten in C specifically to make Unix more portable (portability was something revolutionary at the time... OSes were usually written in Assembly). I'll add something about the "history of C" when I get off work --Eric M Gearhart 06:05, 8 April 2007 (CDT)

in use

C is still in use can be omitted. the 30 years is irrelevant. At this moment over 80% of all compiled compuyter programs that are in use have been programmed in COBOL. Nobody refers to that - so the 30 years here are totally irrelevant - 1972 creation, 2007 now they can do the calculation. Robert Tito |  Talk  16:41, 25 April 2007 (CDT)

Derivatives of C section removed (explaining here)

I removed the following:

==Derivatives==
C has spawned many derivatives, including [[C++]], [[Objective-C]], 
and [[C#]], which are commonly used in programming applications for 
[[Linux]], [[Mac OS X]], [[Microsoft Windows|Windows]] and other 
operating systems.

It is not accurate to call these language derivative of C. All these languages are object-oriented, whereas C is limited to procedural. What these languages do have in common is that they've kept the same syntax style and scope rules, and I have explained that in the opening paragraphs of the article. For example, these languages are all case-sensitive, require semi-colons after statements, segregate code into blocks by means of curly braces, and use automatic or temporary variably scoping within a block. But this syntax is superficial in nature; the underlying capabilities of these languages is far different than for C.Pat Palmer 22:50, 25 April 2007 (CDT)

the point is however they started from C and turned that solution in a superset of C, adding functionality. see for instance gcc/g++. Robert Tito |  Talk  23:15, 25 April 2007 (CDT)

The C++ standard says that is is "based" upon "C" and it gives the history of how "C" was "transformed" into "C++". Richard Williams 17:18, 26 July 2008 (CDT)

Variants

The article should list the variants of "C". C90 and C99 are the main standards, but there are also pre-C90 versions of "C". 04:26, 26 July 2008 (CDT)

Ancestry

Rather than argue about what was inspired by C, I thought it would be useful to detail its ancestry. Howard C. Berkowitz 11:34, 26 July 2008 (CDT)

Pros and cons; code efficiency

Pat made the point of C being more efficient in going to native code, and, in my first cup of coffee, absolutely agreed. After a few more sips, I thought it might be appropriate to reflect on how efficient is still:

1. Highly desirable
2. More achievable in low-level programming languages than high-level
3. Easier in C than in assembly, given a good assembly programmer

In the late sixties and early seventies, if I was going to run a FORTRAN program more than once, I turned on the IBM compiler feature that showed me the object code it produced, and I'd decide if certain parts should be rewritten in assembly. As I moved more and more into the operating system in those days, I was primarily writing assembly for anything that had to run quickly, and either PL/I or SNOBOL for things where I was still trying to think through the logic of the solution, not the efficiency of the code.

A little later, though, I found myself writing in FORTH for a very small PDP-8, and found it ran about as efficiently as anything else. The explanation I was given at the time was that on the PDP-8, with its very small set of instructions and registers, context switching took so long that a tight interpreter would be quite efficient. Emphasize "tight" here; BASIC was slower than FORTRAN.

"C is ' a language that combines all the elegance and power of assembly language with all the readability and maintainability of assembly language. — MIT Jargon Dictionary as well as many T-shirts.

My programming returned to real-time protocol analyzers, and some of that had to be in assembly to do processor-specific things. The big religious argument of the time (early 80s) was C vs. PASCAL, with the PASCAL argument being that strong typing led to much saving of test time, and it also made for more readable programs.

Today, I look around me, and my colleagues doing several real-time medical systems use LUA (an interpreter, interestingly first developed for gaming); they save C for report generation and such. Java and JVMs are widespread, and the distribution of JVM's is Akamai's approach to application acceleration. I hear very little about ADA, but C definitely is around in real-time systems. We have hardware abstraction layers and virtual machines and lions and tigers and bears, oh my! to hide the nuances of the actual hardware.

Juniper router code is mostly C, with a very hardware-specific assembly kernel; there are real-time functions that could be C and outside the kernel, but the key developer felt that on the order of a couple of thousand lines of assembly was justified.

So -- as a serious question -- how important is the efficiency aspect of C? Perhaps there is an article waiting to be born about the choice of languages? Simply because they are required by the operating environment, I'm having to use Java and Javascript, and am still feeling my way through Perl, and trying to decide if some other quick-and-dirty language is better than Perl -- I do regard Perl as rather ugly.

Howard C. Berkowitz 10:37, 27 July 2008 (CDT)

It is not a property of the "C" language that it has to be compiled. There are "C" interpreters. Similarly there exist Java native languages compilers. Java code which is compiled will be faster and more efficient than "C" code which is run through an interpreter.

I would contend it is debatable if "C" is an efficient language. I am aware of at least one high performance "super chip" which is programmed in a subset of Java. Richard Williams 14:53, 27 July 2008 (CDT)

I agree--the efficiency is a function of the compiler or interpreter. A stack-oriented language such as FORTH can be interpreted with great efficiency, although the program reads as if it were written by Yoda. (If Yoda Force so powerful in is, why put words right order he in not can the)?

Given that point, should the article continue to list as a "Pro" that "C is very efficient. C programs can either be compiled or run through an interpreter." I would suggest removing it.Howard C. Berkowitz 18:27, 27 July 2008 (CDT)

The fact that "C" programs can and are being run through interpreters should appear somewhere in the article. I recommend that the statement that "C" is efficient be removed. This statement is somewhat similar to saying that "C" is a "good" language. Instead the article should say something along the lines of: the following feature(s) of the language make it possible for a compiler to produce efficient code. Richard Williams 15:37, 27 July 2008 (CDT)

Anyone want to put in the relevant features? Howard C. Berkowitz 18:27, 27 July 2008 (CDT)

Recent modifications

I have been trying to grow and adapt this article a little bit. When I looked at the article recently, I felt that a number of topics were covered only superficially and tended to state the conventional party line without adding anything new or useful. For example, "C programs are more efficient" than other languages. This is no longer true in all cases, and the ability to understand why may require substantial understanding of computer architecture and operating system software. So I've tried to make the wording a little more precise without going into why I've put it like that in all cases. What's really needed is links to related articles, such as "pointer", "stack", "heap", "garbage collection". I will try to look these up when I get time. Have to quit working on this for now and get back to paying work.Pat Palmer 17:52, 8 January 2009 (UTC)

Hello world in ANSI or K&R?

The current article features an ANSI-style 'hello world' example, states that it was included in K&R's book, and refers to the 1979 edition. That book however predates the ANSI standard, and the particular hello world included was not the same as that in the article (so I am reasonably sure, lacking a copy myself). For instance, the #include <stdio.h> was not there and the main function did not specify int as its type (although again, I do not have a copy in front of me).

Should the reference be changed or is this distinction not significant; what do you think? Perhaps someone with a more thorough understanding of 'K&R C' (and the 1979 book!) could make more clear the distinction between 'K&R' and ANSI C? Johan A. Förberg 13:53, 12 June 2010 (UTC)

We should use ANSI syntax in examples, and should reference K&R second edition which is updated for ANSI C. Sandy Harris 16:34, 12 June 2010 (UTC)

Patriotic aspects?

Should it be mentioned that one interpretation of the U.S. national anthem's lyrics is "Oh, say can you C?" Doesn't the "rockets' red glare" reflect the attitude of management faced with late software, and the "bombs bursting in air" with inadequately tested C control software for missiles? Howard C. Berkowitz 20:00, 18 June 2010 (UTC)

Howard, you've possibly been drinking too much coffee :-).Pat Palmer 01:53, 20 June 2010 (UTC)

I know I've seen the claim somewhere that the Roman Empire fell because, lacking a zero, they had no way to terminate C strings. Should we link to [1]? Sandy Harris 08:29, 20 June 2010 (UTC)

I was the network architect for the U.S. government Y2K center, which had signs everywhere, "The Y1K problem caused the Dark Ages." Howard C. Berkowitz 08:33, 20 June 2010 (UTC)

C summaries

Back in the 80s, I wrote & taught an introductory course on C. My first slide had three quotes. Two were:

• Pascal for grownups
• A macro assembler on steroids

I've forgotten the third, and the attributions for the first two, blast it.

Hoare did a paper around the notion that pointers are to data structures as GOTOs are to control structures, obviously necessary down at the assembly code level but highly undesirable at higher levels. Like jumps, they should be carefully hidden by the language & compiler to make programmers less likely to shoot themselves in the foot. This might be mentioned in the advantages/disadvantages section. Sandy Harris 21:41, 16 July 2013 (UTC)