Delphi-PRAXiS - C++ lernen..

Hi,
auch wenn es kaum etwas zu dem ausführlich Beitrag von mkinzler zu ergänzen gibt, möchte ich mich doch an einer Ausführung versuchen ;-)

Erstmal vorab, mkinzler hat natürlich Recht, wenn Du mit .net anfangen möchtest, dann nimm eine der genannten Sprachen. Aber soweit ich Dich verstanden habe, geht es nicht allein um die beste Sprache für das .Net Framework oder doch?

Wohin die Reise bei C++ und Delphi geht, das ist echt nicht einfach zu sagen (gerade für Delphi). Bei C++ kann man eigentlich davon ausgehen, dass es die noch ein ganzes Weilchen geben wird und auch eine Menge SW in dieser Sprache entstehen dürfte. Das liegt einfach daran, dass C++ Compiler für sehr unterschiedliche Plattformen verfügbar sind (z.B. die Unix-Derivate und Windows) und diese in der Regel sehr gut optimieren. Zudem erzeugen die Compiler typischer Weise nativ ausführbaren Code, dieser ist somit immer etwas schneller als der managed code, den man für eine Java- oder .Net-Laufzeitumgebung braucht.
Über die Vor- und Nachteile kann man sich lange streiten, tatsache ist, dass es Probleme gibt für die C++ besser geeignet ist und solche, bei denen das nicht der Fall ist. So erzeugt man zwar schnellen, nativen Code, muss aber auch für jede Plattform neu übersetzen. Zusammen mit bedingter Compilierung und Makros lässt sich da recht hässlicher, schwer lesbarer Code erzeugen. Ist aber nicht C++ vorbehalten! Findet man auch in jeder anderen Sprache und liegt immer nur am Entwickler. Jedenfalls kann es (je nach verwendeten Bibliotheken) schnell dazu kommen, dass bestimmte Teile sich von Platform zu Plattform doch recht stark unterscheiden (die Windows - API findet man halt unter Linux oder AIX nicht). Zudem ist der C++ - Code eben nicht gemanaged. Das heißt vorallem mal, dass man sich selbst um die Speicherverwaltung kümmern muss. Erzeugt man ein Objekt oder reserviert man Speicher, muss man selbst für die Freigabe sorgen. Vergisst man das, nun ja, ist blöd und gibt Speicherlecks.

Beim .Net - Framework bekommt man eben managed Code und linkt gegen quasi-plattformunabhängige Bibliotheken. Eine vollständige, zum aktuellsten Standard konforme Laufzeitumgebung gibt es eigentlich nur für Windows (und hier kann man spekulieren, ob dies irgendwann sogar nur für bestimmte Windows Versionen gelten wird). Jedenfalls wird der Code in einer Form erzeugt, dass dieser auf einer virtuellen Maschine lauffähig ist. Die Laufzeitumgebung übersetzt erst zur Laufzeit den Code in Befehle, die auf der tatsächlichen Maschine verfügbar sind. Das ganze geht zwar dank heutiger JIT (Just In Time Compiler) recht flink, aber braucht natürlich mehr Zeit als wenn man diesen Schritt weglässt. Der Vorteil ist, dass man den gleichen Code (ohne jegliche Änderung) auf jedem System ausführen kann, für dass eine Laufzeitumgebung existiert.
Zudem hat man den Vorteil, dass der managed code sich eben selbst um die Speicherverwaltung kümmert. Dazu werden einfach die Referenzen auf jedes Objekt gezählt und sobald es Speicher gibt, auf den nicht mehr verwiesen wird, kümmert sich eine Garbage Collection (GC) um die Freigabe. Speicherlöcher sind damit nicht mehr möglich. Die GC wird dabei i.d.R. asynchron aufgerufen, man weiß also nicht genau wann der Speicher mal wieder geleert wird (und natürlich braucht auch die GC ein paar Ressourcen).

An sich gehen die Unterschiede sicherlich noch viel weiter und sie sind andererseits auch klein (je nachdem, worauf man den Fokus legen möchte). Für abstrakte und große Probleme geht der Trend klar hin zum Einsatz von Frameworks (natürlich gibt es auch C++ Frameworks!). Das .Net Framework ist nur ein weiteres, dass auch gleichzeitig als Komponentenmodell betrachtet werden kann. Es stellt dabei eben die Möglichkeit zur Verfügung Komponenten Plattformübergreifen zu nutzen und bietet zudem die Sicherheit, dass man Speicherlecks vermeidet. Die .Net Sprachen (insbesondere C#) nutzen die Votteile des Frameworks recht gut und arbeiten relativ abstrakt. Ganz klarer Vorteil der moderneren Sprachen liegt darin, dass diese häufig von Altlasten befreit wurden. So ist C# deutlich strenger objekt orientiert als es C++ ist. Bei C++ liegt das natürlich nicht zuletzt an der versuchten bzw. benötigten Kompatibilität zu C. Die OOP von C++ macht zwar ebenfalls ein sehr abstraktes Arbeiten möglich (es gibt auch gut abstrakte Frameworks), aber es ist hier auch möglich sehr systemnah zu programmieren.

Wenn Du also fragst, ob es sich noch lohnt C++ (ohne .Net) zu lernen, dann hängt das sehr stark davon ab, was Du eigentlich machen möchtest. Für systemnahe Programmierung lohnt es sich bestimmt noch ein ganzes Weilchen. Willst Du z.B. ein Betriebssystem programmieren oder an einem bestehenden mitarbeiten, so hilft C++ sicher auch weiter. Totzdem muss man nochmal sagen, dass C++ nicht auf diese systemnahe Welt beschränkt ist. Wie gesagt, man hat auch alles um beliebig abstrakt zu arbeiten (und kann sich natürlich auch einen eigenen Speichermanager erzeugen und das .Net Framework nachbilden). Auch der umgekehrte Fall ist möglich. So gibt es bei MS auch ein Projekt, dass ein auf dem .Net Framework basiertes OS als Ziel hat.
Auf lange Sicht werden sicherlich deutlich mehr Komponenten/Bibliotheken und Frameworks für .Net entstehen, die eben alle "modernen/aktuelle" Ansätze umfassen. Willst Du also möglichst einfach schöne GUIs erstellen, auf DirectX aufsetzen und/oder möglichst gut aktuelle elekt. Formate unterstützen, dann wirst Du es sicherlich mit .Net leichter haben. Die Betonung liegt auch wirklich auf dem Leichter, da es immer auch anders möglich ist (nur eben teilweise arg aufwendig und fehleranfällig).

Ja, eigentlich findest Du zu dem ganzen Komplex rund um .Net schon einiges an Diskussion, wo Du sicherlich auch mehr lesen kannst, was viele über die Zukunft von Delphi denken. Wo es aber letztlich hingeht kann sicherlich keiner voraussagen. Wichtig ist halt wirklich nur, was Du machen möchtest, die Programmiersprache bestimmt nur wie einfach Du das erreichst.

Gruß,
Der Unwissende