Unterschied c c++ c#

Sebastian Pizer

Die folgenden Beschreibungen entsprechen meiner Sicht auf die Sprachen C, C++, C#. Mein Background: über 20 Jahre Programmiererfahrung, darunter Basic (C64, Amiga500 bis QuickBasic auf X86), Pascal (Borland), X86 Assembler, C, Delphi, Java (über 8 Jahre, vergleichbar mit C#), Matlab, C++ (seit knapp 3 Jahren) mitgemacht -- ungefähr in dieser Reihenfolge mit Überlappungen.

C bietet im Prinzip "low-level Frickelei pur" (überspitzt, im Vergleich zu den anderen Sprachen zu sehen). Die Sprache bietet nicht besonders viele Abstraktionsmechanismen an bzw unterstützt den Programmierer nicht besonders dabei, leicht benutzbare Abstraktionen zu schaffen. C wird ab und zu als "Portables Assembler" beschrieben:

"The Development of the C Language" (Dennis Ritchie)

Ritchie schrieb:

... More recent descendants of C proper include Concurrent C, Objective C, C*, and especially C++. The language is also widely used as an intermediate representation (essentially, as portable assembly language) for a wide variety of compilers, both for direct descendents like C++, and independent languages like Modula-3 and Eiffel. ...

Obwohl einige Eigenschaften (wie zB Wertebereiche und Speicherlayout von Ganzzahltypen oder structs) plattformabhängig sind, kann man trotzdem "portabel" programmieren, indem man sich nur an den Garantien orientiert, die der ISO C Standard macht. Damit dürfte ein mit Bedacht geschriebenes C Programm, welches keine platformspezifischen Eigenschaften ausnutzt, überall kompilierbar sein.

C++ kombiniert C mit mehr vom Compiler unterstützte Abstraktionsmechanismen und erlaubt eine angenehmere "high-level"-Programmierung. Intention von C++ war es, "ein besseres C" zu schaffen, ohne dass es dabei auf Kosten der Performanz geht ("zero overhead principle" als Designkriterium). Leider ist die Sprache, wenn man sie in ihrer Gesamtheit inklusiver aller Regeln komplett verstehen will, relativ komplex. Es gibt oft sehr viele Wege, die zum Ziel führen und man braucht etwas an Erfahrung, um die Sprachmittel effektiv einsetzen zu können. Der Wert von guten Lehrbüchern zu C++ wird leider von Neuligen zu oft unterschätzt. Auf der anderen Seite benötigt man genauso in C einiges an Erfahrung und Disziplin, um "richtig" zu programmieren.

C# ist so ziemlich das Gegenteil von C. Die anderen beiden Sprachen machen es Anfängern leicht, sich Fallstricke zu bauen. C# bietet "high-level" Abstraktionen, automatische Speicherverwaltung und "Referenz-Typen" statt Zeiger. Aber nichts, was man zur "low level"-Programmierung zählen würde. In C# ist es beispielsweise nicht möglich, den Speicher "versehentlich" zu korrumpieren (zB durch ungültige Zeiger). Ein Teil der Sicherheit wird durch Performanzverlust (Geschwindigkeit & Speicherverbrauch) bezahlt, ein anderer durch den Verlust der Möglichkeiten zur "low-level-Manipulation". Dafür steht einem aber auch automatisch eine sehr umfangreiche "Standard"-Bibliothek zur Verfügung.

Gruß,
SP

Edit1: Nachtrag von Michael's "C# Standard-Bibliothek"-Punkt
Edit2: Zitat für "portable assembly language" eingefügt
Edit3: Meinen Background eingefügt

Michael E.

Auch darf man bei C# nicht die mächtige Bibliothek nicht unterschätzen, die dabei ist. Mit dieser werden viele Standardaufgaben erheblich einfacher.

Sebastian Pizer schrieb:

Ich bin eigentlich nicht an einem Flame-War interessiert ...
C bietet ist im Prinzip "low-level" Frickelei pur.

Troll!

truecolor

An alle erst mal vielen Dank.

Sorry, wenn meine Frage etwas Laienhaft rüberkam, dies hier war definitiv nicht als Troll-Thread gedacht

Wenn ich so eure Ausführungen durchlese fällt sehr eindeutig meine Wahl auf das wohl "weniger anspruchsvoll" C#. Ich reihe mich damit wohl eher in die Gruppe "angstfreies Töpfern in der Toscana" ein als dass ich mich in die Tiefen des Machbaren stürze.

Woran oder ab wann erkenne ich dass es sich um C# handelt?

Gibt es schon unterschiedliche Schreibweisen beim "Hello World" - Programm?

Hier 2 Hello worlds:

#include <iostream>
using namespace std;
int main()
{
  cout<<"Hallo Welt\n";
  cin.get();
}

using System; 
class Hello { 
  static void Main()
  { 
    System.Console.WriteLine("Hello World"); 
  } 
}

das erste, was auffällt is, das man bei C# keine includes mehr benutzen muss. Und beim using muss man nichtmehr sagen, das es sich um einen Namespace handelt.

o_O schrieb:

Hier 2 Hello worlds:
#include <iostream>
using namespace std;
int main()
{
  cout<<"Hallo Welt\n";
  cin.get();
}
using System; 
class Hello { 
  static void Main()
  { 
    System.Console.WriteLine("Hello World"); 
  } 
}
das erste, was auffällt is, das man bei C# keine includes mehr benutzen muss. Und beim using muss man nichtmehr sagen, das es sich um einen Namespace handelt.

Und man brauch keine seltsamen Zeichen wie << bei der Ausgabe.

Sebastian Pizer

Rolleyes schrieb:

Sebastian Pizer schrieb:

Ich bin eigentlich nicht an einem Flame-War interessiert ...
C bietet ist im Prinzip "low-level" Frickelei pur.

Troll!

Gut, das war ein bisschen überspitzt -- wundert mich deswegen auch nicht, dass ich so einen Kommentar bekommen habe. Sicherlich kann man das auch anders formulieren. Ich bleibe aber bei dem Standpunkt. Ich behaupte mal relativ fit in C als auch C++ zu sein. Ich weiß, dass man in C auch "guten Code" (gut entkoppelt, hoher Grad an Kapselung) schreiben kann. Aber C++ bietet mir einfach Dinge, auf die ich nicht verzichten will und einen gewissen Luxus erlauben (zB Destruktoren und sich selbst verwaltende Standardcontainer) während man in C eher genötigt ist, das Rad neu zu erfinden (beispielsweise, was die Speicherverwaltung eines std::vector<T>-Ersatzes angeht) oder einfach mehr aufzupassen (Gefahr von Ressource-Lecks ohne Destruktoren und RAII-Idiom ist höher).

Gruß,
SP

Sebastian Pizer schrieb:

...während man in C eher genötigt ist, das Rad neu zu erfinden (beispielsweise, was die Speicherverwaltung eines std::vector<T>-Ersatzes angeht).

Das ist falsch. Für C gibt es Bibliotheken für alles Mögliche, nur sind sie nicht gleich mit dabei wie in C++.

Wenn Du den Luxus umfangreicher, mitgelieferter Bibliotheken brauchst, dann nimm doch besser C#

Sebastian Pizer schrieb:

C wird ab und zu als "Portables Assembler" beschrieben.

Wenn C portables Assember ist, dann ist C++ ein portabler Makro-Assembler.

Sebastian Pizer

Rolleyes schrieb:

Sebastian Pizer schrieb:

...während man in C eher genötigt ist, das Rad neu zu erfinden (beispielsweise, was die Speicherverwaltung eines std::vector<T>-Ersatzes angeht).

Das ist falsch. Für C gibt es Bibliotheken für alles Mögliche

...streite ich gar nicht ab, dass es Bibliotheken für alles Mögliche gibt. Das sehe ich aber nicht als Widerspruch zu "in C eher genötigt das Rad neu zu erfinden". Es entspricht auch eher meinen Erfahrungen, dass sich viele das ein oder andere "gerade mal eben schnell" selbst stricken. Gut, man kann das jetzt sicherlich teilweise damit erklären, dass es "schlechte" Programmierer gibt -- egal in welcher Sprache. Es liegt mir auch fern, eine Sprache deshalb zu verurteilen, weil es zig Zeilen schlechten Code in dieser Sprache gibt -- etwas, womit Linus Torvalds anscheinend kein Problem hat. Du kannst natürlich argumentieren, dass Du alles besser machst, und tolle Bibliotheken benutzt. Dann würde mich aber wirklich interessieren welche das wären. Machen wir's mal konkreter: Welche Bibliothek kann Deiner Meinung der STL das Wasser reichen und ist populär genug, dass ein nicht zu verachtender Teil der C Programmierer weiß, welche Bibliothek Du meinst? Kann ja gut sein, dass ich da einfach etwas nicht mitbekommen habe. Wie sieht es mit der Generizität aus? Wenn ich eine generische verkette Liste benutzen will, komme ich um void* und Makro-Orgien herum? Wie sieht es mit der Typsicherheit aus?

Rolleyes schrieb:

Wenn Du [...] brauchst

Ich brauche vor allem keine Entscheidungshilfe mehr. Du kannst höchstens meinen Eindruck von C etwas verbessern. Ich wäre Dir sogar dankbar dafür.

Maschinensprachler schrieb:

Wenn C portables Assember ist, dann ist C++ ein portabler Makro-Assembler.

Nee, da beiß ich jetzt nicht drauf an. Musst Du Dir schon mehr Mühe geben.

Nachtrag: Man kann offensichtlich viel Zeit mit so einem Thema vertrödeln. Mir geht auch langsam die Lust aus. Ich verweise jetzt einfach mal auf zwei Texte.
- Linus "I hate C++" Torvalds
- Eine Antwort dazu von Stephen Dewhurst

Gruß,
SP

Tachyon

Wie wäre es mit Java? Java hat ebenfalls eine C-ähnliche Syntax und bringt ebenfalls eine Bibliothek mit sich, die für fast alle gängigen Probleme Lösungen anbietet.

Beispiel:

class MainClass {

	public static void main(String[] args) {
		System.out.println("Hello World!");
	}
}

Die Ähnlichkeit zu C# ist irgendwie frappierend. Ist mir bis jetzt noch gar nicht so aufgefallen. Ein Schelm, wer dabei böses denkt.

erik.vikinger

Hallo,

klar kann man sich mit C/C++ viel leichter selber ins Knie schießen, aber dafür hat man aber auch mehr Kontrolle über das was wirklich passiert. Wenn man diese Kontrolle nicht braucht ist C# oder Java sicher die bessere Alternative, auch sind die viel umfangreicheren Standard-Bibliotheken, die C# und Java fest eingebaut haben, ein wichtiges Argument. Für C und C++ gibt es auch ne Menge Bibliotheken aber die muss man sich erst zusammen suchen und deren Qualität beurteilen, zumindest für C++ scheint da ja demnächst etwas Entspannung in dieser Problematik zu kommen wenn Boost in den Sprachstandard aufgenommen wird (der Rückstand gegen C# oder Java wird damit trotzdem nicht aufgeholt sondern nur etwas verkleinert).

Was ich persönlich an Java vermisse sind die fehlenden Destruktoren, da muss man teilweise ne Menge Aufräumarbeit händisch durchführen. Auch Mehrfacherbung hab ich schon mal in Java vermisst (je es gibt Interfaces die oft reichen aber man kann eben nicht von mehreren richtigen Klassen funktionierenden Code erben). C# hat meines Wissens nach ebenfalls keine Destructoren und auch keine echte Mehrfacherbung.

Als Entscheidungskriterium würde ich "Kontrolle vs. Standard-Bibliothek" empfehlen. Die Syntax ist bei C, C++, C# und Java insgesamt recht ähnlich, mal davon abgesehen das in C keine Klassen, Exceptions u.ä. existieren. Wer eine der drei letzten Sprachen gut beherrscht wird die anderen automatisch zumindest etwas lesen können.

Ich persönlich bin froh das ich meistens mit C++ (und manchmal C) arbeiten kann, ich arbeite aber auch oft mit Assembler und bin es daher gewohnt die volle Kontrolle zu haben.

Grüße
Erik

Sebastian Pizer schrieb:

Ich verweise jetzt einfach mal auf zwei Texte.
- Eine Antwort dazu von Stephen Dewhurst

The argument that abstraction and efficiency are mutually-exclusive or that they're mutually exclusive in the context of C++ is demonstrably false. Lately, much of my work involves writing embedded code in C++ with heavy use of inheritance and templates, and the results have been more than promising. The resultant code is typically smaller and faster than the equivalent (well-written) C code provided by the board's manufacturer

Hier steht eine verwaschene Aussage gegen die andere. Man sollte wirklich mal nachforschen, wer von beiden recht hat. Warum benutzt beispielsweise Apple ObjectiveC anstatt C++? Hatte Linus' Meinung darauf Einfluss?

Marc++us

TrollEyes schrieb:

Hier steht eine verwaschene Aussage gegen die andere. Man sollte wirklich mal nachforschen, wer von beiden recht hat.

Wahrscheinlich keiner und beide.

Es macht kaum Sinn, letztlich kann man in jeder der hier genannten Sprachen Programme schreiben, die nicht funktionieren und den Anwender nerven. Und das ist ja in der Masse der Fälle das, was die Entwickler tun.

Sebastian Pizer

TrollEyes schrieb:

Sebastian Pizer schrieb:

Ich verweise jetzt einfach mal auf zwei Texte.
- Eine Antwort dazu von Stephen Dewhurst

The argument that abstraction and efficiency are mutually-exclusive or that they're mutually exclusive in the context of C++ is demonstrably false. Lately, much of my work involves writing embedded code in C++ with heavy use of inheritance and templates, and the results have been more than promising. The resultant code is typically smaller and faster than the equivalent (well-written) C code provided by the board's manufacturer

Hier steht eine verwaschene Aussage gegen die andere. Man sollte wirklich mal nachforschen, wer von beiden recht hat.

Das Problem ist -- wie so oft -- dass viele Leute, die sich an solchen Diskussionen beteiligen nur einen kleinen Teil des Ganzen sehen. Ich will mich da auch gar nicht komplett ausschließen. Wenn man nicht offen für Argumente ist, ist das hier doch sowieso Zeitverschwendung.

Wenn Dir das also eher wie eine verwaschene Aussage vorkommt, dann liegt das vielleicht daran, dass Du den Teil des Ganzen nicht kennst, welcher für Steven selbstverständlich ist und als Grundlage für diese Aussage verwendet wird. Um's dann überzeugender zu machen, müsste er alles detaillierter beschreiben und mehr Beispiele bringen, damit auch Leute, die nicht wissen, wovon er redet, nicht im Regen stehen gelassen werden.

Ich denke, dass ein erfahrener C++ Programmierer einen etwas besseren Überblick über die Sprachen hat, als einer, der in C++ kaum Erfahrungen hat -- allein deswegen, weil C++ den Programmierstil von C erlaubt, aber nicht umgekehrt. Daher traue ich einem erfahrenen C++ Programmierer einen fairen Vergleich zu. Anderen nicht. Ich halte es für plausibel, dass "andere" eher durch Vorurteile beeinflusst werden.

Ich war aber trotzdem wieder überrascht, als ich die Texte von anderen Autoren aus der git Mailingliste erneut gelesen habe. Vorurteile, Doppelmoral, Verallgemeinerungen, etc etc etc. Die Stimmung, die da rüber kommt, ist auch keine gute Diskussionsgrundlage.

TrollEyes schrieb:

Warum benutzt beispielsweise Apple ObjectiveC anstatt C++? Hatte Linus' Meinung darauf Einfluss?

Die Entwicklung von ObjC und C++ verlief, wie es aussieht, einigermaßen parallel in den 80ger Jahren. Das NeXTStep Betriebssystem hatte 1989 schon eine ObjC-basierte Benutzeroberfläche, welches auch Grundlage für Apple's Cocoa ist. Linus Torvalds wurde erst später bekannt. Der Mann hat die Weisheit auch nicht mit Löffeln gefressen. Er unterliegt selbstverständlich auch der Problematik, nicht den kompletten Überblick zu haben. (Wer hat den schon?) Und über Geschmäcker muss man auch nicht streiten.

Gruß,
SP

erik.vikinger

Hallo,

TrollEyes schrieb:

Hier steht eine verwaschene Aussage gegen die andere. Man sollte wirklich mal nachforschen, wer von beiden recht hat.

Solange alle Programme auf der exakt selben Hardware laufen sollte man theoretisch mit C und C++ gleich schnelle Programme hin bekommen. In C++ kann man sich auf C beschränken und in C kann man C++ händisch nachbauen. Beide Compiler erzeugen Maschinen-Code und wenn einer von beiden besseren Maschinen-Code erzeugt dann weil der entsprechende Programmierer die Problemlösung besser formuliert hat. Theoretisch, entsprechend Know-How und Masochismus vorausgesetzt, kann man C++ auch in Assembler nachbauen und damit funktionsgleichen Maschinen-Code erzeugen. Wenn man in C++ sehr viel mit Vererbung und virtuellen Methoden (was zusätzlichen Code erzeugt) macht kann ein geübter C Programmierer sicherlich effizienteren Code erstellen, dafür ist das C++ Gegenstück eventuell besser wartbar oder leichter wiederverwendbar. Wenn man die Features von C++ nur so viel wie wirklich nötig einsetzt kann man IMHO effizienten und wartbaren Code schreiben, aber dafür braucht man einiges an Erfahrung in C++ und C.

Nur allein mit dem Kriterium Effizienz kann man C und C++ IMHO nicht unterscheiden da beide auf die selbe Basis aufsetzen.

C# und Java dagegen erlauben es nicht in dem Umfang an der Effizienz zu drehen weil dort einige Dinge (z.B. Pointer) vor dem Programmierer versteckt bzw. in Sicherheit gebracht wurden. Für normale Anwendungsprogramme ist das eher von Vorteil und der minimale Effizienz-Rückgang fällt auf heutigen PCs kaum auf. Wenn man aber sehr kritischen oder hardware-nahen Code schreibt kann es schon zum Problem werden wenn man nicht die totale Kontrolle hat.

C und C++ erlauben dem Programmierer mehr aber erwarten auch mehr vom Programmierer.

Grüße
Erik

Shade Of Mine

erik.vikinger schrieb:

Solange alle Programme auf der exakt selben Hardware laufen sollte man theoretisch mit C und C++ gleich schnelle Programme hin bekommen.

Durch unterschiedliche Abstraktionsebenen hat der Compiler unterschiedliche Ansätze zur Optimierung.

rüdiger

@erik.vikinger
Ich würde soger eher sagen, dass man mit C++ durch Templates einen Performancevorteil rausholen kann. Einfaches Beispiel ist ja std::sort vs qsort .

rüdiger schrieb:

@erik.vikinger
Ich würde soger eher sagen, dass man mit C++ durch Templates einen Performancevorteil rausholen kann. Einfaches Beispiel ist ja std::sort vs qsort .

Aber nur mit Integers, nicht mit beliebigen Objekten.
Dafür kann C# sogar zu Laufzeit Optimierungen vornehmen :p

Shade Of Mine

Trollinger schrieb:

Aber nur mit Integers, nicht mit beliebigen Objekten.

Warum nicht mit beliebigen Objekten?

Der Performance Vorteil von std::sort gegenüber qsort liegt ja darin begraben, dass der Compiler bei std::sort die compare Funktion inlinen kann, bei qsort aber nicht.