C, C++, C#

[mZer0]

Abend.

Ich weiss, ihr habt solche Fragen schon 100mal beantwortet. Ich habe in vielen Foren gelesen, welche Sprache ich wirklich lernen sollte.

Möchte eigentlich C++ lernen, einige professionelle meinen ich soll mit C anfangen, und viele andere meinen dass ich auf C verzichten soll und gleich mit C++ starten soll.

Leider kann ich mich jetzt nicht mehr entscheiden.

Bitte helft mir.

Was ist der Unterschied?

 

[Scheuch]

Nunja ... C, C++ & C#

Kommt darauf an, was du machen möchtest. Möchtest du Windows-Applikationen erstellen, wäre C# eine ganz gute Wahl - für Unix hingegen C. C++ ist (ganz grob) gesagt C mit Objektorientierung und eine der verbreitetsten Sprachen.

 

[SheepShaver]

Zudem ist C gemessen an den heute üblichen OO-Sprachen äußerst hässlich und Du solltest lieber gleich mit C++ bzw. C# anfangen. C wird eigentlich nurnoch da verwendet, wo es auf Performance ankommt.

 

[Green Mamba]

Kann mir mal jemand erläutern warum für Unix C am besten ist?
Ich sehe da keinen Zusammenhang. Zudem kann imho mit C++ genauso performante Programme geschrieben werden wie mit C. Wo soll da der Unterschied/Overhead sein!?

@mZer0
Benutz bitte mal die Suchfunktion, es gibt etliche Diskussionen zu diesem und ähnlichen Themen. Prinzipiell ist es gar nicht so wichtig wie du denkst, welche Sprache du zum Anfangen wählst. Hauptsache es ist eine Objektorientierte, da diese heute die am häufigsten verwendete Form von Programmiersprachen in der Anwendugnsprogrammierung ist.
Wenn du eine beherrschst, lernst du eine weitere in kurzer Zeit. Es geht da wohl eher ums Prinzip. C++ ist daher schonmal eine sehr gute Wahl.
Mit C# gewöhnst du dich vielleicht gleich am Anfang zu sehr an dessen Erweiterungen und Eigenheiten. Daher empfehle ich dir C++, da du damit keine Bindung in Form einer bestimmten Plattform eingehst.

 

[SheepShaver]

Ein objekt-orientierter Ansatz bringt immer einen zusätzlichen Overhead mit sich. Daher sind C Programme performanter und lassen sich auch einfacher optimieren. Sprich: wenn man möglichst hardwarenah programmieren möchte, und nicht gleich runter auf Assembler gehen will, dann verwendet man beispielsweise C. Für was anderes sollte C wirklich nicht mehr verwendet werden, da der Code gerade bei größeren Projekten nicht mehr gescheit wartbar ist.

 

[Morgoth]

Für was anderes sollte C wirklich nicht mehr verwendet werden, da der Code gerade bei größeren Projekten nicht mehr gescheit wartbar ist.

Erzähl das mal Theo de Raadt. Der hat da ne ganz eigene Meinung zu. Was soll an großen Projekten an C nicht mehr wartbar sein?

Nebenbei lässt sich auch mit C ansatzweise objektorientiert programmieren, natürlich nicht mit den ganz tollen Features wie Vererbung usw. GTK verfolgt so einen Ansatz ( http://www.gtk.org/tutorial/c24.html , dritter Absatz)

Und C ist portabel, wenn man es richtig anpackt. Und damit meine ich richtig portabel, einen C-Compiler findet man für fast jede Plattform.

Gruß
Morgoth

 

[SheepShaver]

Große C-Projekte sind NICHT mehr gescheit wartbar, vor allem für Außenstehende, die eigentlich nur mal eben eine Erweiterung einbauen sollen. Glaubs mir, ich darf mich mit sowas täglich rumplagen.
In der Zeit, die ich jetzt als Software Entwickler arbeite gab es kein einziges Projekt, wo man nur ansatzweise in Erwägung gezogen hätte, C zu verwenden, außer eben kleinere Subsysteme, die besonders schnell sein sollten, wie z.B. Dekoder, Mustererkennung oder dergleichen.

 

[Green Mamba]

Nunja, ich arbeite seit kurzem in einer Firma, deren Produkte stark Performanceabhängig sind (Virtual Reality, Simulation, Rerchencluster, Verteilung...)
Dort ist noch niemand auf die Idee gekommen mit C zu arbeiten weils damit schneller läuft. Meinen Informationen zufolge hat da C++ keine Nachteile, vor allem wird der von dir angesprochene Overhead durch moderne Compiler ausgemerzt. Daher kann man imho nicht davon sprechen dass C++ in irgendeiner Weise vom Konzept her langsamer ist. Es kommt natürlich immer darauf an, WIE man programmiert.

 

[Morgoth]

Große C-Projekte sind NICHT mehr gescheit wartbar, vor allem für Außenstehende, die eigentlich nur mal eben eine Erweiterung einbauen sollen.

Also behauptest Du, dass Open-, Net- und FreeBSD (das OS an sich, nicht die Ports und Packages) nicht mehr wartbar sind? Die sind nämlich in reinem C geschrieben und für meine Begriffe "groß".

@GM:

Du hast alleine schon einen Overhead weil Du auf private-deklarierte Variablen nur mit Funktionen zugreifen kannst (kann man das umgehen?). Jeder Aufruf kostet Zeit. Und bei virtuellen Funktionen wird AFAIK auch immer erst ein Lookup in der vTable gemacht. Kostet alles Zeit. Ob man das bei den heutigen Rechenwerken noch merkt, vor allem bei GUI-Programmierungen (der Mensch ist ja so langsam!), steht auf einem anderen Blatt.

Gruß
Morgoth

 

[SheepShaver]

@GreenMamba
Ich kann nur von meinen eigenen Erfahrungen sprechen und ich glaube nicht, dass ich bis jetzt nur mit Amateuren zusammengearbeitet habe, die ihr Handwerk nicht verstehen.

@Morgoth
Du hast meine Aussage in ein Absolutum umgeändert, wie ich es nicht formuliert habe.

 

[Morgoth]

Ich kann nur von meinen eigenen Erfahrungen sprechen

Dann ist die allgemein gehaltene Aussage

da der Code gerade bei größeren Projekten nicht mehr gescheit wartbar ist.

aber nicht sinnvoll. Du kannst ja nicht von Dir auf den Rest der Menschheit schließen.

Ich glaube auch nicht, dass Du mit Amateuren zusammengearbeitet hast. Aber jeder halt manchmal so seine liebgewonnenen Weisheiten, und wenn ich sehe, wie an meiner FH (und vermutlich vielen anderen auch) den Informatikern nur noch OOP beigebracht wird, dann weiß, woher diese Weisheiten kommen könnten.

Gruß
Morgoth

 

[SheepShaver]

Naja ich denke mal, der objekt-orientierte Ansatz hat sich einfach durchgesetzt, weil er in der Tat elegant ist und man mittlerweile auf einen unermesslich großen Berg an Erfahrungswerten zurückgreifen kann. Für jede nur erdenkliche Problemstellung gibt es breits das passende Entwurfsmuster. Das heisst natürlich nicht, dass irgendwann mal nicht was neues kommen könnte.

 

[Morgoth]

Naja ich denke mal, der objekt-orientierte Ansatz hat sich einfach durchgesetzt, weil er in der Tat elegant ist

Elegant ist er, keine Frage.

Durchsetzen dagegen ist so eine Sache. Natürlich wird OOP in den nächsten Jahren die Szenerie beherrschen, vor allem da gerade "neue" populäre Sprachen (Java, C#, oder auch Skriptsprachen -> Ruby) objektorientiert sind.

Aber wer weiß, was kommt?

Und wie ich schon sagte: auch in C kann man teilweise objektorientiert programmieren. Z. B.:

struct MyObject {
  int a;
  int b;
};

void set_a(struct MyObject obj);
void set_b(struct MyObject obj);

int get_a(struct MyObject obj);
int get_b(struct MyObject obj);

int summe(struct MyObject obj);

.
.
.

In diesem Beispiel ist die Struktur ein Objekt mit den Membervariablen a und b. Die darunter deklarierten Funktionen sind die Methoden des Objektes, mit denen man auf die Member zugreifen kann. Das Beispiel könnte man in C++ ganz einfach als eine Klasse mit public-deklarierten Variablen schreiben. Wo wir schon bei einem Nachteil wären, nämlich der fehlenden Kapselung.

Gruß
Morgoth

 

[7H3 N4C3R]

Ein objekt-orientierter Ansatz bringt immer einen zusätzlichen Overhead mit sich.

Das ist grundsätzlich falsch. Lies mal Lippmans "Inside the C++ object model".

 

[Morgoth]

OK, da ich keinen Zugriff auf eine gutsortierte Uni-Bibliothek habe: erklär mir kurz, wie das bei C++ gemacht wird (auch bei anderen Sprachen?). Denn ich habe anderes gelernt, und das wäre ja sehr erfreulich wenn man weiß, dass Professoren auch mal Scheiße labern.

Gruß
Morgoth

 

[7H3 N4C3R]

Puh, das ist alles etwas langwieriger. Im Prinzip wird in dem Buch gezeigt, wie C++-Features mit C synthetisiert werden.

Du hast das schon sehr schön dargestellt mit den Funktionen und dem struct. Egal ob das nun das struct ist oder eine Klasse mit Methoden, die Indirektion hat man immer drin. C++-Version hat dafür exakt den selben "Overhead".

Genauso schaut's aus wenn du soetwas wie virtuelle Funktionen unter C brauchst. Du baust dir Arrays von Funktionszeigern auf und reichst die rum. Was anderes sind VMTs auch nicht, nur dass der C++-Compiler hier meist noch wesentlich besser und eleganter ist als ein selbstgestricktes C-Pendant.

Daher kann C++ sogar durchaus (eklatant) schneller sein als C.

Bestes Beispiel dafür ist die Funktion qsort im Gegensatz zu std::sort. Während in C immerwieder die Callback-Funktion zum Vergleichen aufgerufen wird, kann in C++ die ganze Sache geinlinet werden (Inlining gibt's in C nicht. Erst ab C99). Zudem sind das alles Templates, was weitere Indirektion vermeidet. Ein Inlining und eine Vermeidung der Indirektion ist in C garnicht möglich.


Reicht das für den Anfang?

 

[Morgoth]

Du hast das schon sehr schön dargestellt mit den Funktionen und dem struct. Egal ob das nun das struct ist oder eine Klasse mit Methoden, die Indirektion hat man immer drin. C++-Version hat dafür exakt den selben "Overhead".

Soweit klar. Ich kann aber unter C die beiden Variablen in dem struct direkt ansprechen, sozusagen, z. B. mit a=1, ohne auf die Funktion set_a() zurückzugreifen. In C++ muss ich zwangsläufig über die Methode gehen, also einen Funktionsaufruf tätigen, der immer (außer bei inline? dürfte ja eigentlich nicht) Zeit kostet. Oder?

Genauso schaut's aus wenn du soetwas wie virtuelle Funktionen unter C brauchst. Du baust dir Arrays von Funktionszeigern auf und reichst die rum. Was anderes sind VMTs auch nicht, nur dass der C++-Compiler hier meist noch wesentlich besser und eleganter ist als ein selbstgestricktes C-Pendant.

Das hab ich verstanden. Wenn ich das Feature "virtuelle Funktionen" unter C will steh ich nicht besser da als mit C++. Hier also kein Vorteil von C.

Reicht das für den Anfang?

Schaun mer mal.

Gruß
Morgoth

 

[SheepShaver]

Wo soll diese Diskussion eigentlich hinführen? Für die hardwarenahe Programmierung bleibt C die erste Wahl. Natürlich kann ich auch in C++ hardwarenah programmieren, muss dabei dann aber auf sämtliche Vorzüge der OOP verzichten, wodurch ich dann auch gleich sowieso C verwenden kann.
Eine höhere Abstraktionsebene kann NIE zu Gunsten der Performance sein. Das ist ein unaushebelbares Gesetz.