Content deleted Content added
→Economy of expression: there might not be actual "arrays"; bounds violation is already mentioned (more than once) |
m Bot: Converting bare references, see FAQ |
||
Line 4:
==Minimalist design==
A popular saying, repeated by such notable language designers as [[Bjarne Stroustrup]], is that "C makes it easy to shoot yourself in the foot."<ref>[http://www.research.att.com/~bs/bs_faq.html#really-say-that Stroustrup: FAQ<!-- Bot generated title -->]</ref> In other words, C permits some operations that are sometimes not desirable, and thus many simple programming errors are not detected by the compiler and may not be readily apparent at runtime. If sufficient care and discipline are not used in programming and maintenance, this may lead to programs with unpredictable behavior and security holes. (Although this is not unique to C, C provides less protection than do many other programming languages.)
The designers wanted to avoid compile- and [[Runtime|run-time]] checks that were too expensive when C was first implemented. With time, external tools were developed to perform some of these checks. Nothing prevents an implementation from providing such checks, but nothing requires it, either.
Line 79:
* 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.
* Similarity of the assignment and equality operators (<code>=</code> and <code>==</code>), making it easy to substitute one for the other. 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>{{zh icon}} [http://www.cs.ucr.edu/~nxiao/cs10/errors.htm 10 Common Programming Mistakes in C<!-- Bot generated title -->]</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]]".)
| |||