Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Programmieren allgemein (https://www.delphipraxis.net/40-programmieren-allgemein/)
-   -   C++ lernen.. (https://www.delphipraxis.net/110763-c-lernen.html)

bodenheim 24. Mär 2008 14:59


C++ lernen..
 
Hallo,
ich bin Hobby-Programmierer, arbeite vor allem mit Delphi für Win32-Programme.
Jetzt habe ich mir Visual C++ Express08 runtergeladen, um einmal .net-Programe zu schreiben.
Merke, daß das doch sehr verschieden ist..
Meine Frage, lohnt sich das, oder sollte man für .net jetzt eher auf C# setzen? Sollte man C++ können?
Zumal ich mich frage, wohin die Reise bei Delphi geht, und bei C++..

mkinzler 24. Mär 2008 15:00

Re: C++ lernen..
 
Wenn .Net dann besser c# oder Chrome

Der_Unwissende 24. Mär 2008 16:06

Re: 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

idontwantaname 24. Mär 2008 16:09

Re: C++ lernen..
 
Ich (muss fairer Weise sagen, dass ich selbst ausschließlich C# programmiere) würde dir empfehlen, C# statt C++ zu nehmen da die Syntax einige sehr praktische Features mit sich bringt und sehr einfach zu verstehen ist! und daher ideal ist um sich das .Net Framework anzusehen, schon mal weil die Sprache extra dafür entwickelt worden ist ;)

bodenheim 24. Mär 2008 17:38

Re: C++ lernen..
 
Danke für die ausführliche Antwort.
Im Wesentlichen geht es darum, dass ich zwar relativ aufwendige Programme schreiben will, aber als Privatmann
meine geistigen Ressoucen :mrgreen: auch begrenzt sind, das heisst ich muss mich im Bereich C++/C#/.net/Delphi/Java nunmal
entscheiden, und möchte mich nicht falsch entscheiden; zumal ich schonmal auf Java verzichte.
Also wahrscheinlich werde ich mich auf .net/C# konzentrieren.

Der_Unwissende 24. Mär 2008 18:10

Re: C++ lernen..
 
Ja, da stellt sich natürlich auch die Frage, warum Du auf Java verzichtest?

Ich weiß, dass es da äußerst unterschiedliche Meinungen gibt; ich persönlich finde die Sprache sehr sehr gelungen, insbesondere wenn man bedenkt, dass die zu einer ähnlichen Zeit wie Delphi entstanden ist. Entgegen irgendwelchen Gerüchten ist Java jedenfalls nicht wirklich langsam (hat eben die gleichen Nachteile wie .Net). Bei Java kann man aber ein paar Pro's anführen, die man woanders schon etwas suchen muss. So ist Java schon mehr das, was man als "echt" plattformunabhängig bezeichnen kann. Der Compiler ist schon seit Jahren kostenfrei verfügbar und das gleiche gilt (auch seit Jahren) für gute IDEs (allen voran Eclipse bzw. auch NetBeans). Das eigentlich wichtigste ist aber, dass es keine Sprache gibt, für die mehr freie und inbesondere auch OpenSource Komponenten/Frameworks erstellt werden bzw. schon verfügbar sind. Natürlich stösst Java dort an seine Grenzen, wo es um plattform-spezifische Elemente geht, hier hilft allerdings das Java Native Interface (JNI) weiter, mit dem man dyn. Bibliotheken mit einer C - konformen Schnittstelle verwenden kann.

Solltest Du prinzipiell etwas an Java nicht mögen, dann ist C# definitiv die falsche Wahl (die Sprachen ähneln sich doch arg). Natürlich gibt es ein paar Dinge, die Java anders macht als C#, so kennt Java keine Delegaten. Ist da auch eher persönlicher Geschmack, aber ich komme mit der Syntax von Java besser klar, finde die Dokumentation super, finde bei Sourceforge, Apache usw. schnell gute und mächtige Komponenten und weiß auch die "echte" plattformunabhängigkeit zu schätzen. Was die IDEs angeht, so muss ich sagen, dass Eclipse natürlich schon einen anderen Aufbau verfolgt als Visual Studio. Vergleiche sind deshalb (imho) schwierig, da kann ich aber an keiner der Beiden wirklich etwas aussetzen (leider gilt das nicht, wenn man die mit der Delphi-IDE vergleicht, die für ordentlich Geld nicht mal all das bietet, was sich in den freien IDEs findet).

Ja, die Antwort hier ist wohl leicht OT, jedenfalls würde es mich schon interessieren, warum Du Java aussen vor lässt? Ich würde Dir bei der Suche nach einer weiteren/neuen Sprache nicht aussen vor lassen (es sei denn es gibt einen wirklich guten Grund, ich würde ihn gerade nicht sehen).


Alle Zeitangaben in WEZ +1. Es ist jetzt 14:05 Uhr.

Powered by vBulletin® Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2021 by Daniel R. Wolf