Warum programmieren einige noch in C?

Tyrdal

@Wutz Weichei! Turing lehnte damals auch Assembler ab, da man ja wohl noch die Speicherstellen seiner Variablen im Kopf berechnen und somit direkt den Maschinencode schreiben könne. Da kannst du uns mal mit Pussy C gestohlen bleiben.

Was für ein Quark. RAII gibts in C nicht. Punkt! OOP geht bis zu einem gewissen Grad und ja bei Exceptions gehts mit den jumps, ist aber in Sprachen mit Exceptions cleverer gelöst.

Wutz

@Tyrdal
Depp.
Was ist denn das für ein Argument, dass es bei Sprachen, die es als ureigenes Konzept ansehen, Exceptions zu beherrschen, "cleverer" geht?
Depp.

Tyrdal

@Wutz Das ist der Unterschied zwischen "geht irgendwie" und "wird von Sprache unterstützt".

Kannst du auch ohne persönliche Beleidung diskutieren? Du scheinst echt ein sozialer Krüppel zu sein. (Nein, das war jetzt keine Beleidung meinerseits sondern eine ernst gemeinte Vermutung))

RAII in C hast du immer noch nicht wirklich erklärt. Das Wort cleanup reicht da nicht.

Bashar

@Wutz sagte in Warum programmieren einige noch in C?:

@Bashar
Bei gcc+clang gibt es dafür zB cleanup

Ich meinte in C. Dass C plus Compilererweiterung für RAII sowas kann ist trivial. Du hast behauptet es geht in C, also zeig.

Referenzen braucht man nicht, da jeder C-Profi mit Original-Zeigern sowieso besser umgehen kann als es jeder C++ler jemals kann

Jo, alles klar. Ich weiß doch, dass du von C++ keine Ahnung hast. Wieso musst du das direkt wieder unter Beweis stellen, wenn ich dir mal Vorschussvertrauen schenke und dich allen Ernstes sachlich etwas frage? Ich hoffe das sind einfach nur Vorurteile zu C++, die du seit Jahrzehnten wie einen Schatz mit dir herumträgst, und von Dingen außerhalb von C++ hast du zumindest ein bisschen Ahnung. Wetten würde ich darauf aber nicht abschließen.

und OOP kriegt man bekanntlich mit C-Bordmitteln elegant hin, und zwar ohne irgendwas "hinzuhacken";

Bekanntlich? Mir nicht. Sonst hätte ich nicht gefragt.

Tyrdal

Nebenbei ist es fragwürdig sich auf solche nicht standardisierten Erweiterungen zu verlassen. Zumal ein Grund für C ja auch das Vorhandensein eines Compilers auf einer speziellen Plattform sein kann. Das muss dann nicht immer clang oder gcc sein. Die beiden dürften auch nur haben, da sie eh die Funktionalität für ihren C++ Teil brauchen. Der kommt da für C quasi umsonst mit.

SeppJ

@Bashar sagte in Warum programmieren einige noch in C?:

und OOP kriegt man bekanntlich mit C-Bordmitteln elegant hin, und zwar ohne irgendwas "hinzuhacken";

Bekanntlich? Mir nicht. Sonst hätte ich nicht gefragt.

Da hat Wutz aber mal recht. OOP ist eine Philosophie der Programmarchitektur, keine Eigenschaft einer Sprache. Man kann wunderbar objektorientiert in allen imperativen Sprachen programmieren, selbst wenn man Maschinenbefehle auf Lochkarten stanzt. Umgekehrt gibt es jede Menge Code in "objektorientierten" Sprachen mit ganz vielen class & Co. im Code, der überhaupt nichts mit Objektorientierung zu tun hat.

Naheliegendes Beispiel: Weite Teile der C Standardbibliothek sind Musterbeispiele für objektorientierte Programmarchitektur.

Wutz

@Bashar
Referenzen müssen immer initialisiert sein, noch nicht mal nullptr geht.
Damit scheiden sie ggü. Zeigern für einen Großteil der Anwendungsfälle schon mal aus.

Wutz

@Tyrdal
Der Übergang zwischen Weichei/Krüppel und Depp dürfte fließend sein.

Tyrdal

@Wutz sagte in Warum programmieren einige noch in C?:

@Tyrdal
Der Übergang zwischen Weichei/Krüppel und Depp dürfte fließend sein.

Gut, du hast also keine Argumente.

Btw, das Refrenzen kein NULL haben können macht sie ja erst interessant und ist der Grund warum ich sie weitaus öfter als Zeiger verwende.

It0101

@5cript sagte in Warum programmieren einige noch in C?:

Ich behaupte mal das diszipliniertes C weniger messy (unordentlich) wird als einigermaßen diszipliniertes C++.

Denke ich nicht. C++ bietet doch viel mehr schöne Möglichkeiten der Kapselung.

Mein Fehler bei C++ ist wohl dass ich immer versuche alles mit Klassen zu lösen, obwohl ich die selten wirklich gebraucht habe. Vielleicht kommt mir deswegen C einfacher vor. Mit den Klassen in C++ habe ich mich dann oft verhaspelt, mag aber auch an der mangelnden Erfahrung liegen.

Bashar

@SeppJ sagte in Warum programmieren einige noch in C?:

@Bashar sagte in Warum programmieren einige noch in C?:

und OOP kriegt man bekanntlich mit C-Bordmitteln elegant hin, und zwar ohne irgendwas "hinzuhacken";

Bekanntlich? Mir nicht. Sonst hätte ich nicht gefragt.

Naheliegendes Beispiel: Weite Teile der C Standardbibliothek sind Musterbeispiele für objektorientierte Programmarchitektur.

Was soll man dazu sagen... eine Diskussion ist da wohl zwecklos.

Bashar

@Wutz sagte in Warum programmieren einige noch in C?:

@Bashar
Referenzen müssen immer initialisiert sein, noch nicht mal nullptr geht.
Damit scheiden sie ggü. Zeigern für einen Großteil der Anwendungsfälle schon mal aus.

Wieso meinst du, mir das erklären zu müssen?

SeppJ

@Bashar sagte in Warum programmieren einige noch in C?:

@SeppJ sagte in Warum programmieren einige noch in C?:

@Bashar sagte in Warum programmieren einige noch in C?:

und OOP kriegt man bekanntlich mit C-Bordmitteln elegant hin, und zwar ohne irgendwas "hinzuhacken";

Bekanntlich? Mir nicht. Sonst hätte ich nicht gefragt.

Naheliegendes Beispiel: Weite Teile der C Standardbibliothek sind Musterbeispiele für objektorientierte Programmarchitektur.

Was soll man dazu sagen... eine Diskussion ist da wohl zwecklos.

Wieso? Weil du das pauschal ablehnst? Dann spreche ich dir sowohl Ahnung ab, was OO heißt, als auch Diskussionskultur.

Denn ganz klar ist

class File
{
  void open(...);
  int read(...);
};

voll objektorientiert, aber

File* fopen(...);
int *fread(..., File*);

nicht. Völlig unterschiedliche Codingphilosophie. Absolut offensichtlich [/s]

5cript

@It0101
Je mehr der Entwickler sich mit tollen Sprachmitteln verkünstelt, desto weniger steigen andere noch durch.
C sieht immer gleich aus und ist immer gleich aufgebaut.
Eine C codebase mit gewaltigen mengen Zeilen benötigt 0 Einarbeitung.

Was ich auch nicht verstehe, warum muss alles immer mit OOP gelöst werden? Muss man denn jeden "scheiß" in eine Klasse packen und mit DesignPattern generalisieren etc.? Bei einer GUI Lib verstehe ich das noch, aber ansonsten. Muss man denn alles gleich kapseln? Ich habe irgendwie kaum C++ Programme gesehen wo einfach mal ohne eine einzigste Klasse was gelöst wird, warum?

Warum muss es also meist OOP sein?

It0101

@5cript sagte in Warum programmieren einige noch in C?:

@It0101
Je mehr der Entwickler sich mit tollen Sprachmitteln verkünstelt, desto weniger steigen andere noch durch.
C sieht immer gleich aus und ist immer gleich aufgebaut.
Eine C codebase mit gewaltigen mengen Zeilen benötigt 0 Einarbeitung.

Nun ich bevorzuge halt sauber abgetrennte Module. Das stelle ich mir bei C schwer vor.
In C++ hat man sein Objekt und kann dafür N Funktionen aufrufen.

In C hat man im schlimmsten Fall 1000 Funktionen und wühlt sich dann durch die Signaturen, welche wohl zudem passt was man vor hat Alle Funktionen sind zugänglich und aufrufbar. Egal ob sie Sinn machen oder nicht. Ich denke mal das ganze steht und fällt mit der Qualität des Intellisense.

Ich war aber nie besonders stark in C, weil ich frühzeitig mit C++ angefangen habe.

It0101

@Computerwelt sagte in Warum programmieren einige noch in C?:

Was ich auch nicht verstehe, warum muss alles immer mit OOP gelöst werden? Muss man denn jeden "scheiß" in eine Klasse packen und mit DesignPattern generalisieren etc.? Bei einer GUI Lib verstehe ich das noch, aber ansonsten. Muss man denn alles gleich kapseln? Ich habe irgendwie kaum C++ Programme gesehen wo einfach mal ohne eine einzigste Klasse was gelöst wird, warum?

Warum muss es also meist OOP sein?

Weil man mit OOP die Möglichkeit hat, ein streng abgeschottetes Modul zu entwerfen, was nur genau das tut was es soll. Mehr nicht. Mehr ist auch gar nicht möglich, weil durch die Zugriffssteuerung ( public, protected, private ) gar keine Dummheiten gemacht werden können. Die Fehlerquote ist also sehr gering. Das ist natürlich die Idealvorstellung.

Verzichtet man auf Klassen, hat man einen offenen Raum von Funktionen. 80% davon soll der Nutzer gar nicht selber aufrufen, weil sie Hilfsfunktionen sind. Er kann es aber trotzdem tun, was wiederum zu einer erhöhten Fehlerquote führen kann.

Aber bei einem Projekt für sich selbst macht das doch überhaupt keinen Sinn und falls wirklich User(komischer Begriff, das sind für mich die Benutzer meines Programms und nicht andere Entwickler) mit meinen Funktionen arbeiten wollen, so können sie in die Doku schauen welche Funktion was macht. Wer frickelt denn freiwillig mit Funktionen rum, die gar nicht dem Hauptzweck der Lib in der Doku dienliche sind? Nur dafür diesen ganzen Kapselung Klassen Overhead, den man sich funktional komplett schenken könnte? Muss denn jede kleinste Variable als private gemacht werden und einen Getter und Setter bekommen, das alles noch in die Klassen gepackt, wo dann irgendwelche Copy- Move- und was weiß ich noch für Construktor geschrieben werden, um dann am Ende sowas wie die Fakultät auszurechnen etc.? Das ist doch reinste Verschwendung von Codezeilen.

Ich denke mir immer, so wenig Code wie möglich und alles so einfach halten wie es geht. Wenn ich OOP nicht hundertprozentig für die Funktion meines Programms brauchen, dann weg damit. Mal so ganz pragmatisch gesprochen.

Ich finde es unheimlich anstrengend mich durch Klassen zu wurschteln, um zu kapieren was und wie das Programm arbeitet. Zeigermüll ist auch schlecht, aber da komme irgendwie schneller darauf, was da vor sich geht, gibt auch Ausnahmen.

It0101

@Computerwelt sagte in Warum programmieren einige noch in C?:

Ich finde es unheimlich anstrengend mich durch Klassen zu wurschteln, um zu kapieren was und wie das Programm arbeitet. Zeigermüll ist auch schlecht, aber da komme irgendwie schneller darauf, was da vor sich geht, gibt auch Ausnahmen.

Zeiger? nie gehört. Was soll das sein?

Ich finde, dass Klassen eine unglaubliche Erleichterung darstellen, weil sie Probleme kapseln und sauber abgrenzen.

Nicht umsonst gibt es mehr Leute, die C mit Klassen schreiben, als Leute, die C++ ohne Klassen schreiben