Nutzen von C in der heutigen Zeit
-
Wer von euch nutzt heute noch C und für was? Ich will es vielleicht lernen und wollte mich vorab informieren, in wie weit C heute noch in der Programmier-Praxis relevant ist.
-
In eingebetteten Systemen ziemlich relevant.
Lerne es einfach, wenn es dich interessiert. git ist übrigens auch in C geschrieben, obwohl es keine Notwendigkeit bestand.L. G.,
IBV
-
Zwei Stichworte: a) System- und Treiberprogrammierung, b) Unix.
Wer sich nicht für Systemprogrammierung interessiert und mit Windows arbeitet / für Windows entwickeln möchte, braucht auch kein C. Unter unixoiden Systemen ist es aber nach wie vor eine der Haus- und Hofsprachen und durchaus lohnenswert.
Aber auch, wenn man C nur sehr bedingt "braucht", ist es kein Fehler, sich damit zu beschäftigen. Du bekommst ein gutes Gefühl für die internen Abläufe und eine grundsolide Basis für das Erlernen weiterer Sprachen.
-
c)GPU MassiveMultiCore-Programming d)Java JNI e)Numerik?
-
NeuesC schrieb:
Wer von euch nutzt heute noch C und für was?
Dir ist schon klar, dass du durch diese Frage nur Antworten von Leuten bekommen wirst, die C einsetzen?
PS: In diesem Sinne ist dieser Beitrag ausdrücklich nicht als Antwort auf deine Frage zu verstehen, wenn du verstehst, was ich meine.
-
Ich würde auch nicht mehr in C programmieren, aber ich finde es absolut lohnenswert sich damit zu beschäftigen. Es kann auch lohnenswert sein, sich mit Assembler zu beschäftigen, obwohl man es allerhöchstens in Randfällen bräuchte.
Man sollte sich von anderen wirklich nicht davon abhalten lassen, irgendetwas zu lernen.
Manche hier im Forum würden sagen: "Lern C++, weil dann lernst du auch C". Aber das stimmt nicht. In C++ benutzt du die STL welche dir viel Arbeit abnimmt und dir durch die Abstraktion viel verschleiert.
Wenn du C lernen willst, dann lern C und scheiß auf andere Meinungen, denn es gibt so viele davon und jede Richtung ihre starken Persönlichkeiten, von denen sie vertreten wird. Wenn du z. B. nach "Linus Torvalds C++" googlest, wirst du nichts gutes über die Sprache finden. Hat er recht? Ich denke, C++ passt einfach nicht zu seinem Stil, zu seinem Workflow und Denkweise. Es ist einfach nur eine verfickte Meinung und bei seinem Hobbyprojekt Subsurface musste er auch von GTK (C-Lib) auf Qt (C++ Lib) wechseln! :pLiebe Grüße,
IBV
-
- wennn du hardware-/computernahe Programmierung betreiben willst
- wenn du deinen Computer besser/tiefer verstehen willst
- wenn's schnell laufen soll, ohne den ganzen C++ overhead
- wenn ich C++ und C mische, und mich danach fürchterlich abkanzeln lassen will
- wenn man erkannt hat, dass OOP ein genauso überwertetes Konzept ist wie "essen mit einer Serviette auf dem Schoß", achwas wie essen überhaupt
- wenn man von C kommt
- wenn man Spaß dran hat Sachen in einer Sprache zu programmieren, die einem das Denken noch selber überlässt
- wenn man sich Ärger mit den C++ Gurus einhandeln will (von den Javas gar nicht zu reden. Aber die sind in meinen Augen sowieso keine Programmierer im eigentlichen Sinn)
- wenn's extrem kompakt sein soll
- wenn du shellcode und sowas schreiben willst, aber
- wenn dir Assembler dann doch zu kompliziert erscheint
- andere schmutzige SachenFällt mir sicher noch mehr ein, um mich zum Hassobjekt für manche Leute zu machen. :p
-
Ich hatte den Thread gestartet und mich mittlerweile angemeldet, da ich es mit C angehen werde. Die meiste Zeit in meinen Leben habe ich Assembler programmiert, allerdings ist das schon lange her und war damals auf dem Amiga und vorher dem C64. Der Einstieg war, wie bei vielen damals, Basic. Auf meinem ersten 386er PC hatte ich auch ein wenig Assembler programmiert, aber bei weitem nicht so intensiv wie auf dem Amiga. Beruflich ich habe ich gar nichts mit Programmierung zu tun, außer mal ein wenig SPS, ansonsten nur Elektronik.
Ich habe mich in den letzten Wochen viel in Informatikthemen eingelesen(Datenstrukturen, Algos, OOP). Einzig mit OOP konnte ich nicht so viel anfangen. Mir ist schon bewusst, dass ich da alles kapseln kann, aber das habe ich nie gebraucht. Auch für die Vererbung fällt mir nicht viel ein, wo ich das nutzen sollte. Ich will nur kleine Ein-Mann-Projekte, mit dem Schwerpunkt Grafikprogrammierung, schreiben. Also nicht OpenGL, sondern LowLevel, Pixel für Pixel, so wie früher und nur zum Spaß.
-
movem.l schrieb:
Einzig mit OOP konnte ich nicht so viel anfangen.
In den 80-ern war "Objektorientierung" ein Buzzword wie heute "Nachhaltigkeit". 99% der Bücher schreiben nur leeren Mist drüber, mit dem man nichts anfangen kann. Als würde Software auf einmal wiederverwendbar, weil das Kind einen anderen Namen hat.
movem.l schrieb:
Ich will nur kleine Ein-Mann-Projekte, mit dem Schwerpunkt Grafikprogrammierung, schreiben. Also nicht OpenGL, sondern LowLevel, Pixel für Pixel, so wie früher und nur zum Spaß.
Gerade da ist OO ein Segen.
-
NeuesC schrieb:
Ich will es vielleicht lernen und wollte mich vorab informieren, in wie weit C heute noch in der Programmier-Praxis relevant ist.
C wird relevant, wenn du für eine Plattform entwickeln willst, für die es keinen vernünftigen C++ Compiler gibt. Abgesehen davon, gibt es keinen rationalen Grund, heutzutage C zu verwenden, aber natürlich einen ganzen Haufen sonstige Gründe, einige davon hast du hier ja schon zu lesen bekommen...
-
volkard schrieb:
movem.l schrieb:
Einzig mit OOP konnte ich nicht so viel anfangen.
In den 80-ern war "Objektorientierung" ein Buzzword wie heute "Nachhaltigkeit".
Ist es doch immer noch. Es gibt "OOP" als Buzzword für "alles ist eine Klasse mit vielen Gettern und Settern". "OOP" betreiben meist Leute, die das Konzept von Abstraktion nicht ansatzweise verstanden haben.
movem.l schrieb:
Ich habe mich in den letzten Wochen viel in Informatikthemen eingelesen(Datenstrukturen, Algos, OOP). Einzig mit OOP konnte ich nicht so viel anfangen. Mir ist schon bewusst, dass ich da alles kapseln kann, aber das habe ich nie gebraucht.
Das kommt mit der Zeit, wenn deine Spaghettiprogramme unter ihrem eigenen Gewicht kollabieren.
movem.l schrieb:
Auch für die Vererbung fällt mir nicht viel ein, wo ich das nutzen sollte.
Ist auch gut so für den Anfang.
Die Faustregel für später ist: Einswitch
über einenenum
-Typ sollte vielleicht besser ein virtueller Methodenaufruf sein.
-
https://www.youtube.com/watch?v=o9pEzgHorH0 Ist zwar für Python, aber kann man auch auf andere Sprachen übertragen, da wird aus 600LOC mit Klassen das ganze ohne Klassen in ein paar Zeilen Code neu geschrieben. Ist natürlich nicht immer machbar, aber es zeigt die Irrsinn unserer Zeit, der mit OOP betrieben wird.
-
Ich vermute mal, dass viele ältere Entwickler so wie ich, gerne mit c programmieren. Wir sind in der Zeit zur EDV gekommen, wo noch mit Assembler und Cobol programmiert wurde. Habe damals sogar selbst noch Lochkarten manuell am Stanzgerät erstellt - die sogenannten Kartenjobs. Zu der Zeit gab es keine Objektorientierung und so Zeug. Man sparte Bytes, wo es nur ging und selbst kleine Tabellenverarbeitungen wurden trotz Cobol in Assembler geschrieben - das Programm sollte ja auch mal fertig werden (laufzeitmäßig). Wir "Alten" sind dadurch sicherlich oftmals so "versaut", dass wir das ganze oo-Geraffel gar nicht kapieren - zumindest mir geht es so - und da ist c, dass ich mir selbst vor ein paar Jahren beigebracht habe, eine dankbare Sprache für PC-Software - insbesondere unter Linux.
Übrigens - modular haben wir damals schon programmiert
anstatt wie in C wert=meine_funktion(x,y); halt
im IBM-Assembler
hpro csect
save (14,12)
halt la 7 meinupro
bal 7
.
.
meinupro ds 0h
* hier wird malocht
mvc x,=c'Wert fuellen'
br 7
Soll doch jeder das verwenden, was ihm am meißten liegt.
-
Ich programmiere nie in C.
Dennoch sollte nach meiner Meinung jeder ernstzunehmende Programmierer die Grundlagen von C koennen, denn es ist so low level, dass man nur ein Mindestmass an Typsicherheit hat und sich gegenueber Assembler die Register und manuelle Stackverwaltung spart. Man hat aber komplett freien Zugriff auf den Speicher und muss alles selber machen, wodurch man auch versteht wie die Maschine und damit auch die anderen Programmiersprachen arbeiten.Ausserdem hat C das einfachste, einheitliche Funktionsaufruf- und Datenstrukturdarstellungsinterface (sorry, mir faellt einfach keine bessere Beschreibung ein). Wenn man also verknuepfungen zwischen verschiedenen programmiersprachen braucht, muss man fast immer auf C ausweichen und Wrapper-funktionen fuer seine Klassen schreiben.
-
pferdefreund schrieb:
Ich vermute mal, dass viele ältere Entwickler so wie ich, gerne mit c programmieren. Wir sind in der Zeit zur EDV gekommen, wo noch mit Assembler und Cobol programmiert wurde. Habe damals sogar selbst noch Lochkarten manuell am Stanzgerät erstellt - die sogenannten Kartenjobs. Zu der Zeit gab es keine Objektorientierung und so Zeug. Man sparte Bytes, wo es nur ging ...
Ich kenne zwar keine Lochkarten mehr, aber Assembler auf dem C64, Amiga und auch PC habe ich auch mitgemacht und C ist mir auch bekannt. Allerdings, wenn ich mir heute meinen C-Code anschaue, den ich vor einem halben Jahr geschrieben haben, dann habe ich viel mehr Schwierigkeiten, als wenn ich älteren C++-Code von mir anschaue, der noch aus meinen ersten Versuchen C++ zu lernen stammt.
Wenn du nichts mit Klassen anfangen kannst, dann nutze keine. Du musst doch in C++ keine Klassen nutzen. Ich nutze Klasse da, wo ich in C eine Struct + Funktionen zu dieser schreiben würde. Der Konstruktor ist halt init_bla, der Destruktor free_bla und dazwischen sind die Methoden halt die Funktionen die was mit den Daten der Struct machen. Nur habe ich durch den Namensraum der Klasse und den Namensräumen an sich viel kürzere Bezeichner für die Funktionen. Alles wird übersichtlicher. Vererbung und die ganzen Designpattern nutze ich so gut wie nie, da meine Programme einfach nicht solch einen großen Umfang haben. Aber ich weiß, ich kann sie nutzen wenn es nötig wird und muss dann nicht die Programmiersprache wechseln, oder mit Funktionspointer rumwuseln, denn dann wird C richtig eklig zu lesen.
Also C würde ich für Mikrocontroller und so einsetzen, auf dem Desktop oder auch unter Android mit NDK C++.
-
TyRoXx schrieb:
volkard schrieb:
movem.l schrieb:
Einzig mit OOP konnte ich nicht so viel anfangen.
In den 80-ern war "Objektorientierung" ein Buzzword wie heute "Nachhaltigkeit".
Ist es doch immer noch. Es gibt "OOP" als Buzzword für "alles ist eine Klasse mit vielen Gettern und Settern". "OOP" betreiben meist Leute, die das Konzept von Abstraktion nicht ansatzweise verstanden haben.
Ich habe eher den Eindruck, dass die Leute, die gegen OOP wettern, diejenigen sind, die nicht einmal merken, dass so ziemlich jede größere C-Bibliothek (inklusive wichtiger Teile der Standardbibliothek, z.B. Dateihandling) objektorientiert ist. Bloß weil kein "class" im Code vorkommt, ist es nicht automatisch prozedural.