4. Warum programmiert ihr in C?

Warum programmiert ihr in C?

  • V

    pointercrash() schrieb:

    Aber warum soll jemand alle Features einer eierlegenden Wollmilchsau erlernen, wenn er nur ein Ei haben mag? 😉

    Naja, RAII ist schon lecker. Kein close() mehr vergessen können.
    Und man kann auch jahrzehntelang schöne C++-Programme basteln, ohne einmal
    Expression Templates http://en.wikipedia.org/wiki/Expression_templates
    zu schreiben.
    Ich lasse auch C++-Dinge weg, die mir nicht passen. Im C++-Forum könnte ich als Purist gelten.

    0
  • F

    Ich mag C und mag C++ nicht. Das ist wohl auch eine
    Sache der persönlichen Vorlieben. Ich Programmiere noch
    in Java gerne. Ich denke, es gibt keine universelle
    Programmiersprache und jede hat ihre Schwächen und Stärken -
    sonst gäbe es ja die Anderen nicht.

    Das es mit C viel mehr Arbeit macht und machmal auch
    zum Eierlegen ist, größere Projekte umzusetzen ist wohl
    war. Das es trotzdem geht, beweist meiner Ansicht
    nach das Gimp Tool Kit. Vielleicht sollte man sich auch
    immer mal daran erinnern, das C mal geschaffen wurde ein
    Betriebsystem zu schreiben.

    Ich finde es viel wichtiger, das man in der Programmiersprache,
    mit der man arbeitet, oder wie hier auch schon mal angedeutet
    wurde muß, hehe, sauberen Code hinzulegen und das auch das rauskommt
    was man erwartet. Unter diesem Aspekt ist das eigentlich egal,
    welche Programmiersprache der Programmierer gerade benutzt.

    Den Anwender später, interessiert das wahrscheinlich überhaupt nicht.
    Er würde vermutlich über solches Köpfe_heiß_reden hier nur den
    selben schütteln.

    In diesem Sinne

    viele Grüße

    festus0815

    0
  • ?

    piMalDaumen schrieb:

    C ist deutlich einfacher als C++. Nur leider bietet es absolut nichts ... (alleine das fehlen eines STL Pendants ist ein Alptraum)

    Es ist wohl müßig, darauf hinzuweisen, dass für fast jedes nur erdenkliche Problem im Laufe der Jahre und Jahrzehnte, die C mittlerweile auf dem Buckel hat, sehr gute und oftmals hochspezialisierte Bibliotheken entstanden sind, auf die ein C Programmierer zurückgreifen kann. Alleine die lange Tradition von C hat für diesen Umstand gesorgt ... also das 'Rad neu erfinden' wird man eher in allen anderen Hochsprachen müssen. Eine derartige Neuerfindung des Rades wird dort auch öftere Male als 'einen C++Wrapper für ein C-Interface schreiben' bezeichnet.
    Für Hoch- und Skriptsprachen einer noch höheren Abstraktionsebene als C++ wird dann oft ein 'Wrapper für den C++-Wrapper des C-Interfaces' erfunden. Die Russische Puppe wird dabei natürlich immer dicker und schwerer, je öfter sie neuerfunden ('verpackt') wird, und das führt dann bei Low-End-PCs dazu, dass diese dicke C++/Java - Puppe das System überfordert (auch der Vergleich mit einer über-bürokratisierten Verwaltung wäre da treffend).
    Auch das ist nämlich ein wichtiger Grund, dass man möglichst resourcen-schonende Software schreibt (Zwingende Voraussetzung == C):
    Man möchte die Leute mit den Low-End-PCs nämlich nicht von der Nutzung der Anwendung ausschließen!
    Der haarsträubende Dogmatismus, mit dem sich viele C++ - Programmierer selbst verbieten, in manchen Situationen/Teilmodulen im Stile eines C - Programmierers Speicher selbst zu verwalten, sich Gedanken über blockierende und asynchrone
    I/O sowie SysCalls i.A. zu machen, die Cache-Friendliness von mitten im Funktionsrumpf erzeugten Klasseninstanzen zu hinterfragen u.ä. hat dazu geführt, dass jede neue C++ Anwendung immer mehr Resourcen verschlingt (BLOATWARE), und die schillernde Verpackung oft über den katastrophal ineffizienten und wegen 'Über-Verwaltung' meist verbuggten Inhalt hinwegtäuscht.

    Um es kurz zu machen:
    - Als C - Entwickler habe ich in erster Linie das Ziel, zuverlässige, hochperformante, robuste und - für den Anwender komfortable Software/Schnittstellen bereitzustellen.
    - Als C++ - Entwickler möchte man in erster Linie selber komfortabel programmieren, ob dann die Anwender vor der Nutzung des Kompilats erstmal wieder einen neuen Rechner anschaffen müssen, damit der dicke Brummer dann vielleicht halbwegs läuft, interessiert die Herrschaften erst in zweiter Linie.

    Tja, C ist für mich auch heute noch 'Cool', und das trotz vielerlei Abstecher mit durchwachsenen Erfahrungen in die VBasic-, Delphi/Pascal, C++, Java, Ruby, Python, Perl, PHP und neuerdings Squirrel - Welt (Der letzte Schrei!), alles Sprachen, die man bestenfalls für unseriöse Spielereien gebrauchen kann, aber doch nicht in Commercial Quality DB-Backends, Client-/Server- Kommunikation auf der Basis eigener Protokolle, Satelliten-Datei-Formate auf Datenträgern von Alpha-Centauri (oder was weiß man, woher der Quatsch damals kam) und die man nur auf einem alten Kübel aus den 80ern verwenden konnte - halt alles Dinge, die eben auch irgendwer machen sollte. Nicht jeder programmiert immer nur ein cooles Spiel, man höre und staune. Und selbst wenn's so wäre, nähme man dazu wohl eher noch C-Lite, Squirrel, Ruby, Python eher noch her als ein aufgeblähtes OOP-C++ Ungetüm. Denn die systemnahen C-Schnittstellen kann man ebensogut mit diesen Sprachen nutzen, und dazu kommt, dass sich der Einstieg in so eine Skript-Sprache wohl einfacher gestalten dürfte als sich jahrelang irgendwelche C++ - Philosophien reinzuziehen und dann erst wieder nichts weiter zustande zu bringen, als dicke Russische BLOATWARE - Puppen.

    Mag auch sein, dass das Zusammenarbeiten mit anderen C - Programmierern generell unkomplizierter ist als mit so manchen 'ganz besonders gescheiten' C++ 'Experten', die frisch von den FHs kommen, die außer ein paar Schulübungen noch keine hundert Zeilen Quellcode selbständig geschrieben haben und sich dann auch noch über den C - Quellcode von Leuten mokieren, die seit 15 Jahren und manche noch länger in der Firma arbeiten.

    --> So, also eigentlich müsste man sich eher fragen, warum noch irgendjemand in C++ programmiert, wo doch C für die meisten Problemstellungen ganz offensichtlich überlegen und auch flexibler ist.

    MFG

    0
  • ?

    nichtreflexiv schrieb:

    Du hast offenbar noch nie ein großes Softwareprojekt entwickelt - dann würdest du merken, wie unpraktisch C ist und wieso alle modernen Sprachen OOP unterstützen.

    Windows, Linux, Gnome, Gimp sind keine großen Softwareprojekte?

    nichtreflexiv schrieb:

    Was soll überhaupt "unter all dem abgeht" heißen? C++ hat keinerlei Overhead eingeführt. Tiefergehendes Verständnis des Entwicklers hat nichts mit der Sprache zu tun.

    Warum sind dann C++/Qt Anwendungen(KDE) nicht so ressourcensparend wie C/GTK(Gnome) Anwendungen? Wenn du dich wirklich an all die C++ Regeln hälst dann hast automatisch einen Overhead alles andere wäre schlechtes C++.

    Wenn schon OOP dann lieber Java/C# und alles was nicht geht in C. Wie große Projekte zeigen braucht OOP in Wirklichkeit kein Mensch.

    0
  • T

    Da sind ja mal wieder die echten Experten hier versammelt. Natürlich nur zufälligerweise Unregs.
    Kann den Mist mal ein Mod schließen?

    0
  • S

    Didaktiker5, Du sprichst mir aus der Seele.

    Eine Programmiersprache dient zur technischen Umsetzung einer Idee, nichts weiter.
    Das muß sie leisten können, alles andere ist zweitrangig. Was ich dazu nicht brauche
    ist ein bürokratischer Verwaltungsüberbau.

    0
  • ?

    Kann den Mist mal ein Mod löschen?

    0
  • ?

    @this->that: Weil du auch der Experte hier bist *lach

    0
  • ?

    Nö, ich bin grad aus der Gruppensitzung für schwererziehbare Jungendliche heimgekommen und muss noch Aggressionen abbauen 🤡

    0
  • -

    Aber Recht hat er -> Didaktiker5 👍

    0
  • T

    -lowbyte- schrieb:

    Aber Recht hat er -> Didaktiker5 👍

    Aber aus nur aus Sicht eines verblendeten C-Fanboys.

    Über Quatsch wie

    - Als C++ - Entwickler möchte man in erster Linie selber komfortabel programmieren, ob dann die Anwender vor der Nutzung des Kompilats erstmal wieder einen neuen Rechner anschaffen müssen, damit der dicke Brummer dann vielleicht halbwegs läuft, interessiert die Herrschaften erst in zweiter Linie.

    oder

    So, also eigentlich müsste man sich eher fragen, warum noch irgendjemand in C++ programmiert, wo doch C für die meisten Problemstellungen ganz offensichtlich überlegen und auch flexibler ist.

    kann man echt nur den Kopf schütteln. Das is so blöd, das könnt ich fast zu meiner Signatur machen.

    Man merkt deutlich, in welchem Subforum wir uns hier befinden. 😃

    0
  • ?

    this->that schrieb:

    Man merkt deutlich, in welchem Subforum wir uns hier befinden. 😃

    Im Forum für Interessierte der Sprache C. Und warum nun bist du hier? Ach, flamen. Geh lieber SC2 spielen Kleiner.

    0
  • ?

    @this->that

    SC2_Profil .. das sagt schon alles 😃 🙄

    0
  • ?

    Wenn Kinder spielen sind sie gesund. Ich glaube er weiß schon dass ihn keiner ernst nimmt.

    0
  • -

    this->that schrieb:

    Zitat:
    So, also eigentlich müsste man sich eher fragen, warum noch irgendjemand in C++ programmiert, wo doch C für die meisten Problemstellungen ganz offensichtlich überlegen und auch flexibler ist.

    kann man echt nur den Kopf schütteln. Das is so blöd, das könnt ich fast zu meiner Signatur machen.

    <<- Dein Satz ist so B**** das ich ihn jedenfals nicht als meine Signatur möchte !!! 😉 😃

    0
  • P

    volkard schrieb:

    pointercrash() schrieb:

    Aber warum soll jemand alle Features einer eierlegenden Wollmilchsau erlernen, wenn er nur ein Ei haben mag? 😉

    Naja, RAII ist schon lecker. Kein close() mehr vergessen können.

    Im Zusammenhang mit exceptions durchaus bequem, ja. Als C- Progger müßte man sich aber die puristische Frage gefallen lassen, warum man vergessen hat, die Ressourcen zurückzugeben, da ist es schlicht und einfach ein unschöner Bug. Besser, ich gewöhn' mich gar nicht erst an den Gedanken, daß es anderswo kleine Helferlein gibt, das macht nur neidisch.

    Aber da fällt mir eine Sache ein, warum eine Koexistenz durchaus Sinn macht: Wenn ich meine Controllersoftware auf den PC portieren muß und mit einer GUI garnieren, geht's nicht einfacher, als mit dem Gespann C/C++. Die GUI ist in C++ doch schneller gemacht und mein C- Zeugs kann ich einfach mit "extern C" ins Projekt ziehen, schlimmstenfalls muß ich noch 'ne Wrapper- Klasse schreiben und fertig ist der Zauber! Dazu reichen meine C++- Kenntnisse aus und das Ganze ist doch bequemer, als alles in Java nachzufrickeln oder DLLs anzudocken (unschön in Java).

    Eine große Liebe wird das zwar nicht mit mir und C++, aber pragmatisch betrachtet macht es Sinn, wenigstens ein bißchen in C++ reinzuschnüffeln, wenn man C kann. Oder ganz undogmatisch ausgedrückt: Ich kann auch in C Riesenbullshit bauen, ist mir durchaus schon passiert.

    0

  • Es gibt nur einen einzigen rationalen Grund heutzutage C zu programmieren. Und das ist wenn es für eine Zielplattform keine C++ Implementierung gibt.
    Ein nicht rationaler Grund C zu programmieren wäre z.B. das heute relativ weit verbreitete C-Hacker-Syndrom, einige Symptome davon konnten ja auch hier auf den letzten Seiten schon beobachtet werden.

    0
  • T

    dot schrieb:

    Es gibt nur einen einzigen rationalen Grund heutzutage C zu programmieren. Und das ist wenn es für eine Zielplattform keine C++ Implementierung gibt.
    Ein nicht rationaler Grund C zu programmieren wäre z.B. das heute relativ weit verbreitete C-Hacker-Syndrom, einige Symptome davon konnten ja auch hier auf den letzten Seiten schon beobachtet werden.

    Hehe. Klasse Artikel. Beschreibt in der Tat zu 100% unsere Unreg C-Kiddies 😃 👍

    0
  • V

    pointercrash() schrieb:

    volkard schrieb:

    Naja, RAII ist schon lecker. Kein close() mehr vergessen können.

    Im Zusammenhang mit exceptions durchaus bequem, ja. Als C- Progger müßte man sich aber die puristische Frage gefallen lassen, warum man vergessen hat, die Ressourcen zurückzugeben, da ist es schlicht und einfach ein unschöner Bug.

    Ja. Zu jedem open gehort ein close. Fertig. Das ist wie malloc/free oder new/delete, wobei von der Java-Seite her der größte Vorwurf gegen C++ ist, daß man zu jedem new ein delete braucht.
    Das Automatik-Close erlaubt, das Dogma der Strukturierten Programmierung "Single Entry - Single Exit" generell fallenzulassen.
    Ich habe öfters sowas wie

    create...
create...
for...
   if(record.key==tofind)
      return record.value
log("key not found")
return INVALID

    und weiß gar nicht mehr genau, wie ich das in C machte. Vielleicht so?

    open...
open...
found=INVALID
for...
   if(record.key==tofind)
      found=record.value
      break
if found!=INVALID
   log("key not found")
close...
close...
return found

    Naja, die künstliche Variable stört und riecht nach Pascal. Und der Vergleich gegen INVALID stört. Das ist eigentlich eine Information, die im Programmfluß schon steht. Man kann je nach key-Typ den Vergleich billiger machen, indem man einen int/bool mitführt, und zwei künstliche Variablen heraufbeschwört.
    Oder man kann doch oben return machen und die beiden close hochziehen. Damit provoziert man aber, daß man irgendwann ein close vergißt.
    Den Vergleich könnte man mit goto loswerden.

    open...
open...
result=INVALID
for...
   if(record.key==tofind)
      result=record.value
      goto cleanupReturnResult
log("key not found")
cleanupReturnResult:
close...
close...
return found

    Ja, vielleicht so.
    Und auch hier bescheiden bleiben und eher nicht mit "Spracherweiterungen" wie

    #define RETURN(val) {result=(val);goto cleanupReturnResult;}

    anfangen.
    Oder eine wrapping function, die open/close macht.

    pointercrash() schrieb:

    Aber da fällt mir eine Sache ein, warum eine Koexistenz durchaus Sinn macht: Wenn ich meine Controllersoftware auf den PC portieren muß und mit einer GUI garnieren, geht's nicht einfacher, als mit dem Gespann C/C++. Die GUI ist in C++ doch schneller gemacht und mein C- Zeugs kann ich einfach mit "extern C" ins Projekt ziehen, schlimmstenfalls muß ich noch 'ne Wrapper- Klasse schreiben und fertig ist der Zauber!

    Ja, da fängt's dann an. Leider nicht "schlimmstenfalls" ne Wrapper-Klasse, sondern im Prinzip schon verpflichtend. Weil aus C++-Code ja überall eine Exception fliegen kann.

    typedef struct {
...
} ControllerDingens;
ControllerDingens* copen(...);
void cclose(ControllerDingens*);
bool afunc(ControllerDingens*,int);
void bfunc(ControllerDingens*,double);
...
float zfunc(ControllerDingens*,int,int,int);

    und

    ControllerDingens* pcd=copen(...);
char* buf=new char[65536];//könnte Exception werfen
foo();//könnte Exception werfen
bfunc(pcd,3.14);//global error oder pdc->error könnte !=0 werden
winFramework.addButton(...);//könnte Exception werfen
cclose(pcd);

    Ja, das ist doof. Das gefürchtete, wenn man erstmal mit dem Scheiß anfängt, muß man total viel machen, bis es wieder stimmt.
    In C müßte man aber auch unter gede gefährliche Zeile

    if(hatNichtGeklaappt) return ERROR;

    oder sowas machen.

    struct AutoCloseControllerDingens{
   ControllerDingens* pcd
   AutoCloseControllerDingens(...){
      pcd=copen(...);
   }
   ~AutoCloseControllerDingens(){
      cclose(pcd);
   }
/*Wenn man Lust drauf hat
   bool bmethod(double i){//Sowas kostet keine Laufzeit
      return bfunc(pcd,i);
   }
*/
   //und noch Kopieren von AutoCloseControllerDingens verbieten
   private:
   AutoCloseControllerDingens(AutoCloseControllerDingens const&);
   AutoCloseControllerDingens& operator=(AutoCloseControllerDingens const&);
};

    und dann

    AutoCloseControllerDingens cd(...);
char* buf=new char[65536];//könnte Exception werfen, aber cclose wird aufgerufen
foo();//könnte Exception werfen, aber cclose wird aufgerufen
bfunc(pd.pcd,3.14);//global error oder pdc->error könnte !=0 werden
/*Wenn man Lust hat
pd.bmethod(3.13);//global error oder pdc->error könnte !=0 werden
*/
winFramework.addButton(...);//könnte Exception werfen, aber cclose wird aufgerufen
//cclose(pcd);//nicht mehr nötig

    Tja, leider muß soviel wenigstens sein. Also man kann schon in C++ sehr C-ähnlich programmieren, wenn man weiß, was dringend notwenig ist und welche 95% man getrost ignorieren kann.

    Die Controllerschnittstelle in C war übrigens bereits voll objektorientiert. Die wird auch nicht noch objektorientierter, wenn man für die Funktionen noch Wrapper-Methoden anbietet. Sie wird nur C++-üblicher und der geübte C++-Programmierer muß bei Methoden ein wenig seltener ins Handbuch schauen oder kann sich von seiner IDE bessere Tipps holen. Zum Beispiel klappt nach Tippen von "pd." eine Kombobox auf, wo man sich dann einen Funktionsnamen raussuchen kann.

    0
  • ?

    fakt ist, dass c viel besser für librarys geeignet ist als c++. fakt ist auch dass c code viel leichter zu lesen ist, da es keine überladungen anbietet(ja ne ide zeigt das alles schön an, aber machs mal ohne...). dazu kommt der geringere overhead. und dann einfach die pure schönheit der sprache... naja also paar macken haben wir ja alle aber die machen uns nur noch schöner 😉

    wenn ich die codequalität hier im forum von c und c++ vergleiche, dann fällt mir auf, dass bei c-code deutlich penibler auf fehler und returnwerte geachtet wird als in c++ (es verwendet doch jeder new xyz ohne darauf zu achten ob überhaupt speicher her ging...). heißt aber nicht, dass ein guter c++ entwickler dies nicht kann, die meisten machen es einfach aus faulheit nicht.

    0
Anmelden zum Antworten