Criticism of the C programming language: Difference between revisions

Content deleted Content added
m I don't think this was referring to cases commonly diagnosed in practice.
Missing feautures list transplanted from the C article
Line 6:
 
Kernighan and Ritchie made reference to the basic [[design philosophy]] of C in their response to criticism of C not being a strongly-typed language<ref>Brian W. Kernighan and Dennis M. Ritchie: ''The C Programming Language,'' 2<sup>nd</sup> ed., [[Prentice Hall]], 1988, p. 3.</ref>: "Nevertheless, C retains the basic philosophy that programmers know what they are doing; it only requires that they state their intentions explicitly."<ref>{{cite web | author=Dennis Ritchie | url=http://cm.bell-labs.com/cm/cs/who/dmr/chist.html | title=The Development of the C Language | accessdate=2006-07-26}}</ref>
==Missing features==
C lacks features found in some later programming languages:
* No automatic copying of arrays or strings (but structs are automatically copied)
* No [[Garbage collection (computer science)|automatic garbage collection]]
* No bounds checking of arrays and allocated memory segments
* No operations on whole arrays
* No semi-dynamic (i.e. stacked, runtime-sized) arrays until the C99 standard (despite not requiring garbage collection)
* No syntax for [[range]]s, such as the <code>A..B</code> notation used in both newer and older languages
* No [[nested function]] definitions (although some compilers provide them, for example, [[GNU Compiler Collection|GCC]])
* No formal [[Closure (computer science)|closures]] or functions as parameters (only function and variable pointers)
* No [[Generator (computer science)|generators]] or [[coroutine]]s; intra-thread control flow consists of nested function calls, except for the use of the [[longjmp]] or [[setcontext]] library functions
* No [[exception handling]]; standard library functions signify error conditions with the global <code>[[errno]]</code> variable and/or special return values
* Rudimentary support for [[modular programming]]
* No compile-time polymorphism in the form of [[function (computer science)|function]] or [[operator]] [[overloading]]; only rudimentary support for [[generic programming]]
* No support for [[object-oriented programming]]; in particular, no support for polymorphism, [[Inheritance (computer science)|inheritance]] and limited (inter-module only) support for [[Information hiding|encapsulation]], even though there are libraries offering object systems for C, and many object-oriented languages are themselves written in C
* No native support for [[multithreading]] and [[computer networks|networking]], <!-- Better link than computer networks? -->though these facilities are provided by libraries
* No standard libraries for [[GUI|graphics]] and several other application programming needs
 
Although the list of built-in features C lacks is long, this has contributed significantly to its acceptance, as new C [[compilers]] can be developed quickly for new platforms. The relatively low-level nature of the language affords the programmer close control over what the program is doing, while allowing solutions that can be specially tailored and aggressively optimized for a particular platform. This allows the code to run efficiently on very limited hardware, such as [[embedded systems]], many of which today are as capable as the general-purpose machines originally used to implement C.
 
A number of the above missing features are available through the use of third party libraries. Most object oriented functions include a special "this" pointer, which refers to the current object. By passing this pointer as a function argument in C, the same functionality can be performed in C. For example, in C++ one might write:
stack->push(val);
while in C, one would write:
push(stack,val);
where the ''stack'' argument of C is a pointer to a '''struct''' which is equivalent to the ''this'' pointer of C++, which is a pointer to an object.
==Undefined behaviour==