Criticism of the C programming language: Difference between revisions

Content deleted Content added
Tools for mitigating issues with C: Reworked precompiled headers
various supposed improvements had problems
Line 16:
C does not have some features that are available in some other programming languages:
* No assignment of arrays or strings (copying can be done via standard functions; assignment of objects having <code>struct</code> or <code>union</code> type is supported)
* No [[Garbage collection (computer science)|automatic garbage collection]] -- although C would be great for writing the garbage collector for a high-level language's interpreter
* No requirement for [[bounds checking]] of arrays
* No [[array programming|operations on whole arrays]]
Line 78:
* Not checking number and types of arguments when the function declaration has an empty parameter list. (This provides [[backward compatibility]] with [[The C Programming Language (book)|K&R C]], which lacked prototypes.)
* Some questionable choices of operator precedence, as mentioned by Kernighan and Ritchie above, such as <code>==</code> binding more tightly than <code>&</code> and <code>|</code> in expressions like <code>x & 1 == 0</code>.
* The use of the <code>=</code> operator, used in mathematics for equality, to indicate assignment, following the precedent of [[Fortran]], [[PL/I]], and [[BASIC]], but unlike [[ALGOL]] and its derivatives. Ritchie made this syntax design decision consciously, based primarily on the argument that assignment occurs more often than comparison. For those who have trouble understanding it, it might be helpful to think: 'x = 5' means 'make x equal 5'.
* Similarity of the assignment and equality operators (<code>=</code> and <code>==</code>), making it easy to substitute one for the other if you aren't familiar with the language. C's weak type system permits each to be used in the context of the other without a compilation error (although some compilers produce warnings). For example, the conditional expression in <code>if (a=b)</code> is only true if <code>a</code> is not zero after the assignment.<ref>http://www.cs.ucr.edu/~nxiao/cs10/errors.htm 10 Common Programming Mistakes in C</ref>
* A lack of [[infix notation|infix]] operators for complex objects, particularly for string operations, making programs which rely heavily on these operations difficult to read.
* A declaration syntax that some find unintuitive, particularly for [[function pointer]]s. (Ritchie's idea was to declare identifiers in contexts resembling their use: "[[declaration reflects use]]".)
Line 150:
There are dialects of C, such as [[Objective-C]] and [[Cyclone programming language|Cyclone]], that address some of these concerns.
 
Many compilers, notably [[Visual C++]] and [[Xcode]], reduce the long compilation times caused by very large [[header file]]s by using ''[[precompiled header]]s'', a system where the contents of a header are stored in an form designed to be much quicker to process than source text. The one-time neededcost toof buildbuilding a precompiled header filesfile is irrelevantoffset becauseby itthe onlysavings needsfrom tomultiple be done once, outsideuses of the normal compilationfaster processversion.
 
It should be recognized that these tools are not a [[Panacea_Panacea (disambiguationmedicine)|panacea]]. Because of C's flexibility, some types of errors involving misuse of variadic functions, out-of-bounds array indexing, and incorrect [[memory management]] cannot be detected on some architectures without incurring a significant performance penalty. However, some common cases can be recognized and accounted for.
 
== See also ==