Warum programmiert ihr in C?

[spielespiele]

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

[-lowbyte- 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 !!!

[pointercrash**]

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.

[dot]

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.

[this-*gt*that]

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

[volkard]

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.

[__--]

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.

[volkard]

__-- schrieb:

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...).

new wirft in C++ doch eine Exception! Die braucht man nur in der main() abzufangen und fertig.
Deswegen wirst Du NIE in C++

char* buf=new char[size];
if(buf==0) return FEHLER;

sehen. NIE. Also sei nicht traurig, daß Du das im C++-Forum auch nicht zu lesen bekommst. new kann nämlich gar nicht 0 zurückgeben.
Klassischer Fall von "Habe keine Ahnung aber meckere mal.", gell?

[volkard]

__-- schrieb:

fakt ist, dass c viel besser für librarys geeignet ist als c++.

Nö, gleich.

__-- schrieb:

fakt ist auch dass c code viel leichter zu lesen ist, da es keine überladungen anbietet

Nö. abs berechnet den Betrag. Wozu fabs, labs und abs? Wird halt erst einfacher zu lesen, wenn man sinnvolle Überladungen auch erwartet.

dazu kommt der geringere overhead.

Zum Beispiel für die Inline-Wrapper-Methoden von oben? Der Laufzeit-Overhead ist genau 0%. OK, das Compilieren dauert länger. Aber das ist mir egal.

und dann einfach die pure schönheit der sprache...

Ja, das lasse ich mal gelten.

[__--]

volkard schrieb:

__-- schrieb:

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...).

new wirft in C++ doch eine Exception! Die braucht man nur in der main() abzufangen und fertig.

komm ich dann nach der exception wieder dahinzurück wo sie geworfen wurde? oder kann ich dann das programm beenden?

[volkard]

__-- schrieb:

volkard schrieb:

__-- schrieb:

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...).

new wirft in C++ doch eine Exception! Die braucht man nur in der main() abzufangen und fertig.

komm ich dann nach der exception wieder dahinzurück wo sie geworfen wurde? oder kann ich dann das programm beenden?

Konsolenprogramme beendet man normalerweise einfach nur mit der Meldung "Speicher ist alle gegangen". Ganz wie in C. Man kann natürlich auch was anderes machen. Der Waschmaschinensteuerprozess wird natürlich nicht beendet. Klickibuntis geben eine MessageBox aus und tun snst nichts. Je nach dem.

Man kann nicht "zurück", aber man kann eine Exceptions auch woanders als in der main() fangen.

[rüdiger]

Ich programmiere nicht gerne größeren Code in C oder je nach Situation auch kürzeren, wenn man zB viel mit Strings arbeiten muss. Mir fehlen da einfach viel zu oft Templates (zumindest die STL-Container) oder Exceptions oder RAII oder andere Kleinigkeiten. In C ist es schon sehr aufwendig, wenn man etwas wie vector oder string haben will und man sieht oft, dass dort sehr viele Fehler gemacht werden (ala x = realloc(x, n); ). Es stimmt zwar, dass man in C oft schneller sieht, was der Code im Detail macht. Weil eben so etwas wie realloc direkt gemacht wird und man ständig und überall auf Fehlercodes prüfen muss. Aber das macht den Code nicht lesbarer, da man viel zu sehr damit beschäftigt ist, sich durch den Boilerplatecode zu wühlen.

[Famer]

Oh, schon leer. *nachfüllt*

[Scheppertreiber]

Famer schrieb:

Oh, schon leer. *nachfüllt*

Ich hole schon mal Chips und Bier

[frick]

Fakt ist doch das C nur was für Masochisten ist.

[HighLigerBiMBam]

Ich programmiere in C++, C, C# und VB. Meiner Meinung nach hat jeder der Sprachen (auch PHP, Java, etc...) ein deutliches Anwendungsgebiet. Zu behaupten die eine wäre besser als die andere ist schlicht unfug.

Man kann durchaus sagen, dass jede Sprache ihre Vor- und Nachteile besitzt und dadurch eine Daseinsberechtigung hat. Mir fallen auf Anhieb Anwendungsgebiete ein die ich niemals mit C++ schreiben würde, aber auch genügend wo C einfach die falsche Wahl ist.

Es ist durchaus immer gut seinen Horizont für die anderen Sprachen zu öffnen. Schließlich ist aus Sicht eines Unternehmens immer die Sprache entscheidend, welche bei gleichen Ergebnissen die Entwicklungszeiten geringer hält.

Mfg

[--s....]

this->that schrieb:

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

komm geh wider spielen !

[C Fan]

c.ool schrieb:

C liegt genau in der Schnittmenge von klein, schnell und einfach; und da liegt es nunmal ziemlich alleine.

Wobei man D auch noch dazuzählen könnte, nur ist das halt kaum verbreitet und hat kaum Auswahl bei den Compilern.

Ansonsten ist C natürlich klasse, weil das Programmieren mit C noch richtig Spaß macht.
Es ist nicht dieses öde zusammenklicken von Swingtoolboxen usw., sondern man kann da noch richtig was auf Hardwareebene reißen.

[C Fan]

nichtreflexiv schrieb:

Nur weil ihr permanent das Rad neu erfindet, in der Vergangenheit lebt und mit void Pointern rumfrickelt denkt ihr, ihr wärt was besseres.

Oh, danke.

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.
Was soll überhaupt "unter all dem abgeht" heißen? C++ hat keinerlei Overhead eingeführt.

Doch! Geh mal mit nem Debugger durch compilierten C++ Code der Polymorphie bzw. das Überladen von Funktionen nutzt.
Viel Spaß beim zurechtkommen!

Bei C weiß ich wenigstens auch auf Speicherebene im Debugger, welche Funktion welche ist.

[C Fan]

festus0815 schrieb:

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.

Naja, zumindest Javaanwendungen sind bei Anwendern meist eher unbeliebt, was IMO daran liegt, daß selbst das kleinste Programm erstmal die fette JRE Laden muß und das dauert und dauert und nervt nur den Anwender.

Das gleiche Programm (vom Funktionsumfang her) in C und der Winapi geschrieben ist ratz fatz da -> das macht bei Endanwendern beliebt.

Für Java haben die Leute eigentlich nur dann verständnis, wenn sie
A) nichts besseres kriegen. Kennt jemand nen Ersatz zum TV-Browser?
oder
sie Programmieren können und halt das einmalige Starten am Morgen von Eclipse oder Netbeans dulden bzw. gerne in Kauf nehmen.