Unix und C - Was macht C so besonders?
-
Dafür gibt es verschiedene Gründe
a) Tradition. Wenn fast jeder Code eh in C ist, dann programmiert man auch in C
b) C++ Implementierungen, die portabel, schnell und standardisiert waren, gab es erst relativ spät
c) C ist leichter zu lernen, als C++
d) C ist sehr LowLevel (eben ein Macroassembler)
e) Exploits und ähnlich kleine Anwendungen lassen sich schneller mit C entwickeln, als mit komplexeren Sprachen wie C++ oder Java
f) die System APIs sind in C. Mit C++ braucht man erstmal schöne Wrapper, da man ansonsten direkt C nehmen könnte.
...
-
Es können ganz einfach mehr Leute C als C++. Viele können vielleicht auch C++, fragt sich aber nur, ob sie es auch gut genug können. C ist halt einfacher zu erlernen.
-
e) Exploits und ähnlich kleine Anwendungen lassen sich schneller mit C entwickeln, als mit komplexeren Sprachen wie C++ oder Java
Naja, dass es schneller is C-style zu benutzen is wohl wahr aber denoch sind STL Container, STL Algorithmen und IOstreams woll einsetzbar.
Ob man nun
int array[]={5,4,8,2}; //Man könnt eventuel das sizeof(a)/sizeof(a[0]) hinter einem Macro verstecken sort(array,array+sizeof(array)/sizeof(array[0]));oder
int int_compare(const void*,const void*){ /*...*/ } //... int array[]={5,4,8,2}; qsort(array,sizeof(array)/sizeof(array[0]),sizeof(array[0],int_compare);Ist ja von einem C-style Standpunkt her völlig egal, ersterers ist jedoch weniger Tiparbeit und besser lesbar.
Und std::string lässt sich auch gut mit C Schnittstellen einsetzen. Die Verwandlung in ein C String ist ja kinderleicht (string::c_str()). Andersrum wird es ein wenig schwieriger aber denoch
//global const int buf_size=1024; char buf[buf_size+1]; //... GetString(buf,buf_size); string my_str="Prefix"+string(buf)+"Postfix";find ich das will einfacher (und vor allem viel weniger Fehler anfällig) den reine C Strings.
-
@Irgendwer
jo, mit C++ kann man sowas trotzdem programmieren. Aber die anderen Punkte beeinflussen sich ja auch untereinander.btw. für Größenangaben bitte std::size_t benutzen und nicht int!
-
kingruedi schrieb:
btw. für Größenangaben bitte std::size_t benutzen und nicht int!
und für char arrays verwendet man std::vector und nicht std::string!
Wann werden es die Leute lernen?
-
[quote=http://www.c-plusplus.net/geschichte.htm]
C und UNIX ein schlechter Scherz?In einem in der Computerindustrie Aufsehen erregenden Vortrag haben Ken Thompson, Dennis Ritchie und Brian Kernighan zugegeben, daß das von ihnen entwickelte UNIX-OS und die Programmiersprache C von ihnen ursprünglich als Aprilscherz gedacht war, der sich aber seit über 20 Jahren am Leben erhält. In einer Ansprache auf dem kürzlich stattfindenden UnixWorld Software Development Forum äußerte sich Thompson wie folgt:
"1969 hatte AT&T gerade die Arbeit an dem GE/Honeywell/AT&T Multics Projekt beendet. Brian und ich hatten gerade begonnen, mit einer frühen Form von Pascal zu arbeiten, das von Professor Nichlaus Wirths Lehrgebiet an der ETHZ in der Schweiz entworfen wurde. Wir waren von der eleganten Einfachheit und Mächtigkeit der Sprache sehr beeindruckt. Dennis hatte gerade das Buch "Der Herr der Augenringe" zu Ende gelesen, eine urkomische Parodie auf Tolkiens großartige Trilogie "Der Herr der Ringe". Zum Spaß begannen wir, eine Parodie auf die Multics-Umgebung und Pascal zu erstellen. Dennis und ich waren für die Umgebung verantwortlich. Wir schauten auf Multics, und entwarfen das neue System so komplex und kryptisch wie möglich, um die Frustration gewöhnlicher Benutzer so hoch wie möglich zu machen, und nannten es UNIX als Parodie auf Multics, ebenso wie einige andere Anspielungen innerhalb des Systems. Dann begannen Dennis und Brian an einer wirklich verzerrten Version von Pascal zu arbeiten, genannt 'A'. Als wir merkten, daß andere tatsächlich vorhatten, Programme mit 'A' zu entwerfen, fügten wir rasch zusätzliche kryptische Eigenschaften hinzu, und entwickelten daraufhin B, BCPL und schließlich C. Wir hörten auf, als es uns gelang, den Ausdruck
for(;P("\n"),R--;P("|"))for(e=C;e--;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);
fehlerfrei zu compilieren.
Zu denken, daß moderne Programmierer versuchen würden, eine Sprache zu benutzen, die derartige Ausdrücke zuläßt, lag weit außerhalb unseres Verständnisses. Wir dachten daran, das ganze an die Sowjets zu verkaufen, um den Fortschritt ihrer Computerwissenschaft um 20 Jahre zurück zu werfen. Man stelle sich unsere Überraschung vor, als AT&T und andere US-Firmen begannen, es mit UNIX und C zu versuchen! Es kostete sie 20 Jahre, um genug Erfahrung zu sammeln, um wenigstens halbwegs nützliche Applikationen mit dieser Parodie der 60er-Jahre zu erstellen., aber wir waren erstaunt von der Zähigkeit des gewöhnlichen UNIX- und C-Programmierers. Auf jeden Fall haben Brian, Dennis und ich in den letzten Jahren ausschließlich auf dem Apple Macintosh in Pascal programmiert und wir fühlen uns wirklich schuldig an dem Chaos, dev Konfusion und der wirklich schlechten Programmierarbeit, die wir mit unserem unsinnigen Scherz vor langer Zeit angerichtet haben."
Die wichtigen UNIX- und C-Verkäufer und -Nutzer, einschließlich AT&T, Microsoft, Hewett-Packard, GTE, NCR und DEC, haben zum jetzigen Zeitpunkt jede Stellungnahme abgelehnt. Borland International, ein führender Hersteller von Pascal- und C-Tools, einschließlich dem populären Turbo-Pascal, Turbo-C und Turbo-C++, äußerten, daß sie dies bereits seit einiger Zeit vermutet hätten und in Zukunft ihre Pascal-Produkte weiter verbessern wollten, bei gleichzeitiger Einstellung jeglicher Entwicklung für C. Ein IBM-Sprecher brach in unkontrolliertes Lachen aus und mußte eine hastig zusammengerufene News-Konferenz über das Schicksal der RS-6000 aufschieben - lediglich mit der Aussage "VM wird nun wirklich bald zur Verfügung stehen". In einer kryptischen Aussage bemerkte Professor Wirth vom Institut der ETHZ, Vater der strukturierten Sprachen Pascal, Modula2 und Oberon, lediglich, daß P.T. Barnum richtig lag.
In einer ähnlichen Meldung, die vor kurzem hereinkam, sagten üblicherweise zuverlässige Quellen, daß ein ähnliches Geständnis bald von William Gates gemacht werden wird, betreffend das MS-DOS- und Windows-Betriebssystem. Und IBM-Sprecher haben zu leugnen begonnen, daß auch die virtuelle Maschine (VM) ein interner Streich ist, der nach außen gedrungen ist.
Aus: COMPUTERWORLD, April 1st, in freier Übersetzung
Der englische Originaltext ist unter “c-hoax.txt” im Web zu finden.
[/quote]
-
-
1. C is a simpler language so more people are familiar with it, particularly on Unix.
2. C can be wrapped by any other language, making the API available to more developers.
-
Man sollte auch bedenken, dass nicht wenige Programmierer OOP nicht mögen. Sprüche wie OOP ist besser oder schlechter ist sowieso subjektiv. Man kann sehr gute Anwendungen prozedural oder objektorientiert schreiben. Nur macht es gerade im Netzwerkbereich nicht viel Sinn auf oo zu setzten.
Darüber hinaus glauben viele das C schneller ist. Zu dennen zählt auch John C. einer bekannten Spieleschmiede, der alle seine Engines in C schreibt.
-
Nur macht es gerade im Netzwerkbereich nicht viel Sinn auf oo zu setzten.
quatsch. Wie du bereits gesagt hast, hängt OOP eben vom Entwickler ab.
-
** ** ** schrieb:
Darüber hinaus glauben viele das C schneller ist. Zu dennen zählt auch John C. einer bekannten Spieleschmiede, der alle seine Engines in C schreibt.
Der macht das wohl eher, weil er es sich so angewöhnt hat, und seine Gewohnheiten nicht ändern will solange er so zu recht kommt.
Er hatte ja früher vorwiegend deshalb auf OpenGL gesetzt, weil ihm das DirectX Framework zu verkorkst war (was für alte Versionen auch voll zutrifft). Nachher hat er aber seine Aussage revidiert und gesagt, daß die aktuellen Versionen mehr als konkurrenzfähig sind. Trotzdem wechselt er nicht die API
Gewohnheit!
Solange er also mit OpenGL genausoviel erreichen kann, wird er wahrscheinlich dabei bleiben...
Mit C ist's dasselbe.
Der API-/Sprachen-Wechsel sollte ja nicht nur deshalb stattfinden, damit er stattfindet...
-
vorallem kostet es viel Geld. Große Software und gerade Engines werden ja für jedes Projekt nicht komplett neu entwickelt. Man nimmt ja einfach den alten Code un fügt eben noch Support ein, dass die Modelle irgend welche neuen Texturen etc. ausnutzen können oder die Partikelsysteme besser sind.
Aus dem Grund gibt es ja auch noch zahlreiche COBOL und FORTRAN Programme.