Warum programmiert ihr in C?
-
Ich habe z.B. noch nie wirklich OOP gebraucht
Was braucht man schon ... welchen Mehrwert hat diese Aussage?
-
Belli schrieb:
Nicht so voreilig. Es soll noch als SW-Entwickler tätige Informatik-Absolventen geben, die in großen Konzernen kaufmännische Anwendungen entwickeln/weiterentwickeln/pflegen, die auf Großrechnern laufen und in COBOL geschrieben sind, die sich mit Objektorientierung nicht auseinandersetzen müssen.
Zu wenige, um relevant zu sein.
Konstruiertes Beispiel.
-
Mhm, wie viele sind 'zu wenige'?
Und überhaupt, zu wenige Entwickler, oder zu wenige Konzerne? Oder beides?Aber gleich 'konstruiertes Beispiel'?
Das bestreite ich. Es gibt nach wie vor einen Markt für IBM-Mainframes - und vermutlich ebenso für Siemens - Großrechner.Viele große Kommunen unterhalten eine solche Maschine, jede Menge kleiner Kommunen sind an ein Rechenzentrum angeschlossen, welches so einen Mainframe unterhält, im Banken- und Versicherungsbereich spielen Großrechner noch eine bedeutende Rolle - und die jeweiligen Buchhaltungssysteme sind zum größten Teil in COBOL geschrieben.
Ihren Zenit haben diese Rechenanlagen zwar überschritten und der Trend geht in eine andere Richtung, aber noch gibt es eine ganze Menge.
Eine aktuelle Studie:
http://www.pressebox.de/pressreleases/bmc-software-gmbh/boxid/384608
-
@volkard: Betriebssysteme und die meisten embedded Geschichten werden ohne OOP in C geschrieben und auch viele GTK+ Anwendungen wirst du finden die nicht OOP brauchen. Über den Daumen gepeilt wird doppelt so viel Software in C entwickelt wie in C++ . Ich denke da schon dass viele auch komplett ohne OOP gut zurecht kommen und dass es kein Grund gibt nicht gute große Software auch ohne OOP zu schreiben.
-
Nicht so vergessen sind so kleine Programme wie Python, Perl, PHP und Ruby die ebenfalls in C implementiert wurden. Sie sind deswegen ja auch schlecht erweiterbar und extrem unsicher und werden nur bei extrem abgeschirmeten Rechner ohne Netzzugang genutzt und noch der Anwendung gleich wieder deinstalliert.
-
PHP auf einem Rechner ohne Netzzugang?
Das kann ich kaum glauben ...Edit: Da hab ich wohl mal wieder schneller geschrieben als gedacht ...
-
Zwischenruf schrieb:
@volkard: Betriebssysteme und die meisten embedded Geschichten werden ohne OOP in C geschrieben und auch viele GTK+ Anwendungen wirst du finden die nicht OOP brauchen. Über den Daumen gepeilt wird doppelt so viel Software in C entwickelt wie in C++ . Ich denke da schon dass viele auch komplett ohne OOP gut zurecht kommen und dass es kein Grund gibt nicht gute große Software auch ohne OOP zu schreiben.
Hast Du den Thread aufmerksam gelesen?
Es wird erstaunlich viel OOP in C betrieben. Was soll man auch anderes machen, wenn der Chef Angst vor C++ hat oder keine anständigen C++-Compiler für die Plattform zur Verfügung stehen.
Ich glaube fast, Knuth der letze große Künstler, der komplett auf OO Techniken verzichtet.
-
Zwischenruf schrieb:
und auch viele GTK+ Anwendungen wirst du finden die nicht OOP brauchen.
GObject sagt dir schon was oder?
-
Ja klar weiß ich das mit GLip auch OOP möglich ist und dies auch genutzt wird. Es wird nur immer hier großkotzig erzählt dass man in C keine große Software schreiben kann die gut erweiterbar und sicher ist und das ist einfach FALSE.
Ich sehe halt das Optimum darin Sachen die Performance verlangen oder nahe am System sein müssen in C zu schreiben und wenn es denn unbedingt sein muss GUI und auch Logik in Sprachen wie Java/C#/Pyhton oder weiß ich was zu machen. C-Schnittstellen unterstützen die meisten Sprachen C++ Schnittstellen nicht.
Ich sehe den Sinn von C++ einfach nicht.
-
Zwischenruf schrieb:
Ich sehe den Sinn von C++ einfach nicht.
C in eine einfach zu verwendende objektorientierter Sprache zu verwandeln.
-
großkotzig erzählt dass man in C keine große Software schreiben kann die gut erweiterbar und sicher ist
Behauptet niemand. Aber ich behaupte: Es ist ungemein aufwendiger.
Ich sehe den Sinn von C++ einfach nicht.
Diese Beschraenkung ist dein Problem.
C-Schnittstellen unterstützen die meisten Sprachen C++ Schnittstellen nicht.
Das hat andere Gruende.
-
Zwischenruf schrieb:
Ich sehe halt das Optimum darin Sachen die Performance verlangen oder nahe am System sein müssen in C zu schreiben...
sry, aber das ist einfach FALSE.
jede größere lib die ich kenne verwendet im untergrund so viel assembler das dir die augen raus fallen. c wird dort nur als fallback genutzt falls für diese plattform kein assembler code implementiert ist.
und diese assembler schnipsel werden dann schön mit c verkleistert
-
Visual Basic ist beste was gibt. Basta!
Der, der sagt, was Sache ist.
-
__-- schrieb:
jede größere lib die ich kenne verwendet im untergrund so viel assembler das dir die augen raus fallen. c wird dort nur als fallback genutzt falls für diese plattform kein assembler code implementiert ist.
Nenn doch mal ein paar Beispiele. Ich glaube nicht, dass ein nennenswerter Anteil des Publikums hier weiß, was "__--" für Bibliotheken kennt.
-
Visual was? Ich kenne nur Visual fail
-
Bashar schrieb:
__-- schrieb:
jede größere lib die ich kenne verwendet im untergrund so viel assembler das dir die augen raus fallen. c wird dort nur als fallback genutzt falls für diese plattform kein assembler code implementiert ist.
Nenn doch mal ein paar Beispiele. Ich glaube nicht, dass ein nennenswerter Anteil des Publikums hier weiß, was "__--" für Bibliotheken kennt.
Ich als Teil des Publikums weise hier einmal auf die GMP Library hin: Beispiel Repositry Link. Man beachte: 24 Assembler-Ordner und 1 C-Fallback-Ordner (generic). Dafür existiert übrigens auch eine C++ Anbindung.
-
Bei High-Performance-Arithmetik-Bibliotheken ist das ja auch nicht so abwegig. Weitere Beispiele, bitte.
-
Bashar schrieb:
Bei High-Performance-Arithmetik-Bibliotheken ist das ja auch nicht so abwegig. Weitere Beispiele, bitte.
stdlib,bitfields,timing,cpu detection sind so die sachen welche mir spontan einfallen
-
Kein vernünftiges Programm kommt mit OOP alleine aus.
In irgend einer prozeduralen (C-style) Art und Weise müssen die vielen tollen Schnittstellen, die so ein geniales C++ Objekt 'anbietet', ja auch implementiert werden. Prinzipiell stellt man sich intuitiv unter einem Programm in erster Linie einen (zeitlichen) Ablauf vor, und eher weniger ein sinnloses Nebeneinander irgendwelcher Objekte, die einfach nur da sind (es ist ja schön, wenn sie so verschieden sein dürfen!) und mit denen nichts gemacht wird und die auch von sich aus nichts tun. Zum Leben erweckt werden die Objekte ja immer erst dadurch, dass irgendwelche Funktionen mit diesen Objekten auch arbeiten. Also von daher erscheint mir der geordnete Ablauf eines
C-Programms (auch wenn es noch so umfangreich sein sollte)
auch intuitiv leichter nachvollziehbar als eine diffus miteinander verzahnte Klassen- Bibliothek, wo sich alle möglichen Funktionen untereinander in Spaghetti-Manier und in völlig unvorhersehbarer Weise aufrufen.
Selbst dem Programmfluss einer halbwegs passabel strukturierten C-Anwendung mit mehreren Threads kann man da leichter folgen (und z.B. die Korrektheit des Programms unter allen denkbaren Voraussetzungen verifizieren oder falsifizieren). Bei pompösen und wild miteinander verzahnten Klassen-Bibliotheken gibt's meist keinen 'roten Faden', dem man folgen könnte, dort geschehen ja schon bei der Instanzierung irgend einer Klasse meist so viele implizite Nebenwirkungen und Ausflüge in versteckte Quellcode-Abschnitte, dass man bei jeder C++-Quellcode-Zeile ja nur hoffen kann, dass alles so gut geht, wie es sich der Programmierer vorstellt.
Also imho ist C einfach nur die intuitiv logischere Programmiersprache als irgendwelche OOP High Level Sprachen, die man auch in kürzerer Zeit erlernen kann. Selbiges gilt für Bibliotheken, mit denen man als C-Programmierer arbeitet. Es genügt meist, sich die Dokumentation einer Funktion anzusehen, damit man sie nutzen kann. Bei C++ Funktionen (deren korrektes Funktionen meistens von allen möglichen vorausgegangenen Initialisierungen irgendwelcher Objekte X, Y, Z abhängt) kann man erst mal sich je nach Umfang der Library erstmal ein paar Wochen lang mit den Interna / Klassenhierarchien etc. beschäftigen, bevor man etwas mit den Schnittstellen anfangen kann.
Ergo: OOP verkompliziert die einfachsten Dinge. Wo man in C schnell mal unter Zuhilfenahme entsprechender Libraries damit anfangen kann, große Teile eines Programms zu schreiben, findet man sich bei der Verwendung von OOP-Libraries erstmal für mehrere Wochen beim Doku-Studium derselbigen wieder.
-
btw. in linux ist der arch ordner nach den treibern der 2. größte wenn ich mich nicht irre.