Direkt Python, der erst mal C++ lernen ?

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
mephisto-online
User
Beiträge: 167
Registriert: Sonntag 29. September 2013, 17:05

Hallo,

momentan möchte ich meine Computersprachen-Kenntnisse erweitern und danach mit der neuen Sprache ein bereits bestehendes, gemischt-sprachiges Project (C, Java, C#) noch einmal von der Pike auf neu schreiben. Erst hatte ich mich für C++ entschieden, weil ich mein neues Projekt basierend auf den Qt-Bibliotheken schreiben möchte und Qt wohl meines Wissens auch in C++ geschrieben ist. Dann hatte ich mich doch für Python entschieden, weil Qt mit PySide wohl auch in Python sehr gut zu programmieren ist.

Nun wird in den Python- und Pyside-Tutorials immer wieder auf Erfordernisse für die C++-Librarys hingewiesen, wie z.B. hier:
Note the use of the @Slot() decorator above the definition of clicked_slot; though not strictly necessary, it provides the C++ Qt library hints on how clicked_slot should be called.
oder
The datatype may be any Python type name or a string identifying a C++ datatype. Since this tutorial presupposes no C++ knowledge, we’ll stick to Python types.
Quelle: http://www.pythoncentral.io

Ist denn Python im Prinzip so etwas wie ein Interpreter zur Programmierung der C++-Bibliotheken mit der Python-Script-Sprache ?

Eigentlich benötige ich keine Spezialitäten wie z.B. Echtzeit oder so. Deshalb dachte ich eigentlich, dass ich es mir sparen kann, diese sehr komplexe Sprache C++ zu erlernen, wenn ich das, was ich brauche, auch in Python machen kann. Aber solche Aussagen wie oben machen mich etwas skeptisch, ob es nicht doch Sinn machen würde, erst C++ und danach erst Python zu lernen, um die Vorzüge dann mit dem entsprechenden Background zu nutzen.

Was ist Eure Meinung ?

Grüße
mephisto
BlackJack

@mephisto-online: Qt ist in C++ geschrieben und `PySide` oder `PyQt` sind Python-Anbindungen an die Qt-Bibliothek. Die Bibliotheken stellen die Funktionen und Klassen in der Bibliothek als Python-Objekte zur Verfügung. Das Konzept mit den Signalen und Slots von Qt hat mit der Programmiersprache C++ erst einmal nichts zu tun, das ist eine Qt-Besonderheit. Dazu stellt das Qt-Projekt einen speziellen Präprozessor, den „Meta Object Compiler” (``moc``) zur Verfügung und ein Build-Werkzeug ``qmake`` das diesen Compiler kennt.

Meiner Meinung nach sollte man C++ nur lernen wenn es gar nicht anders geht. Ich bin aber voreingenommen weil ich mit der Sprache nicht zurecht komme. Die ist einfach nur höllisch kompliziert und nervig. Und mit Qt zusammen ist sie wohl ein klein wenig erträglicher weil die Bibliothek viele nützliche Sachen bereit stellt und einen bestimmten Stil ”erzwingt”, man also nicht mehr mit der ganzen Komplexität von C++ konfrontiert sein muss.

Um Qt in Python nutzen zu können muss man zwar die C++-Dokumentation der Bibliothek lesen können, aber das ist wesentlich einfacher als tatsächlich in C++ programmieren zu lernen. Es geht hauptsächlich darum das man C++-Funktions- und -methodensignaturen lesen kann und versteht wie man die Informationen aus der Qt-Dokumentation auf Python abbilden muss. Ansonsten werden in der Qt-Dokumentation die Konzepte IMHO sehr gut und ausführlich dokumentiert die hinter den Qt-Klassen stehen und wie die Komponenten zusammen spielen; und das weitestgehend sprachunabhängig.
mephisto-online
User
Beiträge: 167
Registriert: Sonntag 29. September 2013, 17:05

BlackJack hat geschrieben:@mephisto-online: Qt ist in C++ geschrieben und `PySide` oder `PyQt` sind Python-Anbindungen an die Qt-Bibliothek. Die Bibliotheken stellen die Funktionen und Klassen in der Bibliothek als Python-Objekte zur Verfügung. Das Konzept mit den Signalen und Slots von Qt hat mit der Programmiersprache C++ erst einmal nichts zu tun, das ist eine Qt-Besonderheit. Dazu stellt das Qt-Projekt einen speziellen Präprozessor, den „Meta Object Compiler” (``moc``) zur Verfügung und ein Build-Werkzeug ``qmake`` das diesen Compiler kennt.
Mit dem moc, das wusste ich jetzt noch nicht, ich hatte nur mit C++ angefangen, meine Hauptklassen zu deklarieren. Der Rest war mir schon klar.
BlackJack hat geschrieben: Meiner Meinung nach sollte man C++ nur lernen wenn es gar nicht anders geht. Ich bin aber voreingenommen weil ich mit der Sprache nicht zurecht komme.
Oh, das tut gut, mir ging es exakt genau so! Und ich dachte schon, dass ich einfach nur zudummzumzum bin...
BlackJack hat geschrieben: Die ist einfach nur höllisch kompliziert und nervig.
Das fand ich auch. Eigentlich sogar unnötig kompliziert !
BlackJack hat geschrieben: Und mit Qt zusammen ist sie wohl ein klein wenig erträglicher weil die Bibliothek viele nützliche Sachen bereit stellt und einen bestimmten Stil ”erzwingt”, man also nicht mehr mit der ganzen Komplexität von C++ konfrontiert sein muss.
Das habe ich schon direkt am Anfang gemerkt, als ich was mit nem String und der stdlib machen wollte und danach das Ganze mit QString. Aber warum sollte man es einfach machen, wenn es auch kompliziert geht. :lol:
BlackJack hat geschrieben: Um Qt in Python nutzen zu können muss man zwar die C++-Dokumentation der Bibliothek lesen können, aber das ist wesentlich einfacher als tatsächlich in C++ programmieren zu lernen. Es geht hauptsächlich darum das man C++-Funktions- und -methodensignaturen lesen kann und versteht wie man die Informationen aus der Qt-Dokumentation auf Python abbilden muss. Ansonsten werden in der Qt-Dokumentation die Konzepte IMHO sehr gut und ausführlich dokumentiert die hinter den Qt-Klassen stehen und wie die Komponenten zusammen spielen; und das weitestgehend sprachunabhängig.
Das ist alles richtig ! Eigentlich komme ich mit dem Lernen sehr gut voran. Erst habe ich ein reines Python-Tutorial durchgearbeutet und jetzt eines mit dem PySide- bzw. dem PyQt-Package. Erst hatte ich das mit der NinjaIDE gemacht. Das hatte mich aber ständig verunsichert, weil ständig irgendwas angeblich dem Interpreter nicht gefiel. Jetzt, mit PyCharm macht das richtig Spaß. Es waren die Sätze, die ich oben zitiert habe, welche mich verunsichert haben. In diesem Zusammenhang gingen auch ein paar Beispiele nicht, weil da imports drin waren, die einfach nicht existieren und nirgendwo im Text aufgetaucht sind (z.B. from __future__ import print_function). Aber insgesamt fängt es an, dass ich die Sprache Python, erst recht mit den Möglichkeiten von PySide, richtig geil finde.

Aber auf jeden Fall danke für die 100%ige Bestätigung, dass man C++ wirklich nicht braucht, um "ganz normale" Programme zu schreiben.

P.S.: Nur Win7 hat mich ein weiteres Mal enttäuscht ! Hatte ein schönes Tetris-Programm in Python abgekupfert und wollte bei meiner Frau damit ein bisschen Welle machen. Aber bei Win7 muss man Python natürlich erst mal installieren. :evil: Bei Linux geht das immer standardmäßig und beim Mac auch. :)
BlackJack

@mephisto-online: Was dem Interpreter nicht gefällt hängt eigentlich nicht von der IDE ab. Und ``from __future__ import print_function`` funktioniert eigentlich auch in jedem aktuellen Python, also sowohl in Python 2.7 als auch in den 3er-Versionen.
mephisto-online
User
Beiträge: 167
Registriert: Sonntag 29. September 2013, 17:05

Das habe ich mir eigentlich auch gesagt. Nein, ich wollte NinjaIDE nicht schlecht machen ! Ist eine von vielen hoch gelobte IDE. Komme aber mit PyCharm momentan besser klar.

War sowieso mein Fehler ! Die Import-Zeile war nicht ganz am Anfang des Python-Scripts. :oops:
Benutzeravatar
darktrym
User
Beiträge: 784
Registriert: Freitag 24. April 2009, 09:26

Persönlich kenne ich keinen der die Ninja IDE freiwillig nutzen wöllte, deshalb muss man sich nicht schämen funktionierende und durchdachte Software wie PyCharm verwenden zu wollen.
„gcc finds bugs in Linux, NetBSD finds bugs in gcc.“[Michael Dexter, Systems 2008]
Bitbucket, Github
Sirius3
User
Beiträge: 17746
Registriert: Sonntag 21. Oktober 2012, 17:20

Um nochmals auf Qt zurückzukommen: ich halte es sogar für kontraproduktiv C++ zu lernen, da Qt so vieles anders macht als klassische C++-Programme. Qt ist quasi eine eigene Sprache aufbauend auf C++. Ich persönlich habe ein traumatisches Qt/KDE Erlebnis aus meiner Jugend. Liegt wahrscheinlich daran, daß man nach jeder Änderung erst mal eine Stunde warten mußte, bis der Compiler wieder mit einer Fehlermeldung abgebrochen war.
Hellstorm
User
Beiträge: 231
Registriert: Samstag 22. Juni 2013, 15:01

Hier möchte ich mich mal einklinken: Was genau ist denn an C++ eigentlich so schlimm? Ich kann es nicht wirklich (hatte es mal ein wenig gelernt, aber damals noch keinen sinnvollen Einsatzzweck gefunden, so dass ich es wieder vergessen habe), aber so wie es mir scheint ist es einfach vom Konzept anders: Bei Python schon sehr viele Funktionen integriert, bei C++ praktisch gar nichts, aber mit dem Zweck, dass man sich diese halt selber gut schreiben kann.

Und da würde dann Qt ins Spiel kommen, dass die dann als Toolkit anbietet: QString, GUIs, Netzwerkfunktionalität usw.

Aber was ist denn, wenn man davon mal absieht, denn so schlecht? Ich benutze jetzt Python hauptsächlich weil das Kompilieren wegfällt, aber Kompilieren muss man doch bei anderen Sprachen auch. Und all die ganzen anderen Sachen wie Variablendeklaration, Angabe des Rückgabewertes einer Funktion usw. sind doch bei anderen Sprachen auch so.

Mir scheint nur irgendwie, dass der Quelltext von C++ irgendwie sehr schlecht zu lesen ist. Allein um eine Klasse zu deklarieren muss man ja so viel schreiben, dass man gar keine Übersicht mehr hat :D
BlackJack

@Hellstorm: Das C++ keine Umfangreiche Standardbibliothek hat, hat IMHO gar keinen „Zweck” oder Grund, sondern ist wohl einfach der Tatsache geschuldet, dass das ”früher” einfach nicht üblich war.

Aber weder das, noch das kompilieren, noch die statische Typisierung machen die Sprache in meinen Augen ”unbenutzbar”. Mit C oder Pascal oder Java und C# komme ich ja zurecht. Bei C++ ist es einfach die Komplexität und auf was man alles so selber achten muss um sicheren, fehlerfreien Code zu schreiben. Ich bin erst nach Java zu C++ gekommen und mir erscheint es geradezu pervers um was man sich in C++ alles Gedanken machen muss um ein gleich sicheres Programm zu schreiben. Das ist vielleicht auch mein Hauptproblem mit C++: mir fehlt die Motivation mich um Details zu kümmern von denen ich weiss das sich in anderen Sprachen der Compiler oder die Laufzeitumgebung darum kümmert und von denen ich persönlich keinen Vorteil sehe dass ich mich darum kümmern muss. Als ich das erste mal etwas über „exception safety” gelesen habe, dachte ich der Autor will mich verarschen. Erklärt aber vielleicht warum Ausnahmen in C++ selten bis gar nicht verwendet werden. Template-Fehlermeldungen sind auch so eine Sache. Da rauschen seitenweise irgendwelche Informationen über Templates über das Terminal die nahezu allesamt Implementierungsdetails sind, und ausser *das* man einen Fehler gemacht hat, helfen die einem nicht wirklich weiter. Ich glaube es war Fefe der mal gesagt hat das nach seiner Erfahrung selbst C++-Profis an der Stelle betroffenen Quelltext löschen und neu anfangen und hoffen den Fehler nicht noch mal zu machen, als ”Lösungsstrategie” anwenden.

Qt ist ein schlechtes Beispiel denn das macht aus C++ wie Sirius3 ja schon sagte eine ”neue”/”andere” Sprache. So richtig C++ ist eher Boost, von dem ja auch Teile in die tatsächliche Standardbibliothek übernommen werden. Und Boost ist beispielsweise voll von Template-Magie die einen mit den langen unverständlichen Fehlermeldungen konfrontieren kann.

Qt erweitert C++ auf der einen Seite durch seinen „Meta Object Compiler” der Funktionalität bereit stellt, welche man sonst in C++ mit Templates umsetzen würde. Dann ist da die Speicherverwaltung, die bei Qt-Klassen durch die Objektbäume vereinfacht wird. Auf der anderen Seite schränkt Qt den Sprachumfang von C++ auch ein, zum Beispiel in dem durch QObject als Basisklasse „copy constructor” und Zuweisungsüberladung konsequent unterbunden werden, was dem Leser die Frage bei Zuweisungen erspart was da jetzt jeweils konkret passiert.

Ich denke der Anspruch eine abstrakte Hochsprache zu sein bei der man sich trotzdem um die ganzen Low-Level-Details kümmern *muss*, erzeugt ein Spannungsfeld was in C++ sauschlecht ”gelöst” ist. Grund ist wahrscheinlich, dass C++ auf dem Gebiet eine Art Pionier ist und sich vom ursprünglichen Ansatz, einen Satz C-Makros für OOP auf C drauf zu setzen, bis zur eigenenständigen Sprache einiges entwickelt hat was man bei einem kompletten Neuentwurf heute, mit den bisherigen Erfahrungen, nicht mehr so machen würde. Das es auf dem Weg zwischen hardwarenähe und OOP-Abstraktion, also sozusagen zwischen den Extremen C und Java durchaus auch andere Ansätze gibt, zeigen Sprachen wie D und Vala und aktuell auch Rust. Und die zeigen IMHO auch das es offensichtlich Bedarf für eine solche Sprache als Alternative zu C++ gibt.
mephisto-online
User
Beiträge: 167
Registriert: Sonntag 29. September 2013, 17:05

@BlackJack
Das ist ja mal eine sehr reflektierte Darstellung der C++-Problematik, der ich nur unumwunden zustimmen kann ! :D

Aus den dargestellten Gründen hatte ich jetzt auch meine C++-Einarbeitung abgebrochen. Warum soll man "Flöhe hüten" (die auch u.U. zu Elefanten werden können !), um die sich die Laufzeitumgebung kümmern könnte (wie z.B. bei java). Der Rechner kann par Geschindigkeit wesentlich mehr überblicken, als ein Entwickler oder gar mehrere.

Ein Beispiel, was die Problematik recht gut bestätigt:

Einige jahre lang war ich Systemintegrator und Admin in einer Gruppe von 10 C++-Entwicklern und 15 Ingenieuren, die an Energiemanagement-Systemen gearbeitet haben, womit Kraftwerke gesteuert, kontrolliert und optimiert wurden - recht komplexe Systeme und alles in C++ programmiert. Die Entwickeler haben die Basis-Systeme bereitgestellt und die Ingenieure irgendwelche Rechen-Modelle für die Kraftwerks-Komponenten. Es war an der Tagesordnung, dass irgendeins der ca 50 international installierten und 24/7 durchlaufenmüssenden Systeme ausgefallen oder stehengeblleiben ist, was wir dann per Fernwartung per Terminal-Server-Client oder auch nur SSH und Telefon wieder hinbiegen mussten. Sehr häufig waren (eigentlich winzige) Fehler in den C++-Programmen die Ursache. Die Entwickler und Ingenieure fluchten auch regelmäßig über diese Programmiersprache. Als dann C# aufkam, wurde alles ratzfaz Stück für Stück umprogrammiert und die Systeme sind danach auch wirklich messbar störungsärmer geworden.

Aber wie ist das denn nun genau mit Python, was diese Problematik angeht ? Was ist denn da die Laufzeitumgebung, wo es doch irgendwie auch auf C++ "aufsetzt" ? :?

Freundliche Grüße
mephisto-online
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

mephisto-online hat geschrieben: Aber wie ist das denn nun genau mit Python, was diese Problematik angeht ? Was ist denn da die Laufzeitumgebung, wo es doch irgendwie auch auf C++ "aufsetzt" ? :?
Welche Problematik meinst Du denn genau? Du hast irgend wie keine genannt...

Und Python fußt auch nicht auf C++ - CPython, die Referenzimplementierung, ist in C geschrieben. Jython in Java, IronPython vermutlich in C# usw.
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
mephisto-online
User
Beiträge: 167
Registriert: Sonntag 29. September 2013, 17:05

Das Python ein "Überbau" von C++ ist, hatte ich irgendwo gelesen und das habe ich mir dann so gemerkt. Ist wohl falsch ! :oops:

Aber Qt fußt wohl auf C++, das ist doch richtig, oder ? Aber das kann man ja dann auch nicht mehr als C++ im ursprünglichen Sinne bezeichnen, weil Qt C++ ja erst mal sinnvoll erweitert hat. :wink:

Damit ist auch meine Frage bezüglich der "Problematik" hinfällig. :)
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

mephisto-online hat geschrieben:Das Python ein "Überbau" von C++ ist, hatte ich irgendwo gelesen und das habe ich mir dann so gemerkt. Ist wohl falsch ! :oops:
Letztlich ist die Sprache, in der ein Compiler und oder eine Laufzeitumgebung geschrieben ist nicht so wirklich relevant für einen reinen Anwender der Sprache ;-)

Qt ist in C++ entwickelt, ja. Aber wie ja schon dargelegt worden ist, verwandelt Qt C++ zu einem anderen Erlebnis. Natürlich wird dadurch nicht alles gut, aber es ist 1000 Mal besser als z.B. MFC (olles Ms Zeugs).

Ich persönlich möchte keine Sprache mehr benutzen, die keinen eingebauten Garbage Collector bietet. Imho eine der schlimmsten Sachen an C++ ist diese Suppe aus manuellem Freigeben von Speicher und den verschiedenen Übergabemöglichkeiten... vermutlich führt das eben auch so oft zu Fehlern, da so oft per Unfall ein Objekt gelöscht wird, welches an anderer Stelle noch gebraucht wird.
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

ich denke in C++ ist das Problem auch, dass man sehr viele Freiheiten hat Sachen zu erledigen die dann subtil unterschiedliche Ergebnisse haben. Nicht umsonst haben größere Firmen C++ Styleguides wo beschrieben wird auf welches C++ Subset man sich einigt und was ok ist und was zu vermeiden ist.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
EyDu
User
Beiträge: 4881
Registriert: Donnerstag 20. Juli 2006, 23:06
Wohnort: Berlin

Hyperion hat geschrieben:Ich persönlich möchte keine Sprache mehr benutzen, die keinen eingebauten Garbage Collector bietet. Imho eine der schlimmsten Sachen an C++ ist diese Suppe aus manuellem Freigeben von Speicher und den verschiedenen Übergabemöglichkeiten... vermutlich führt das eben auch so oft zu Fehlern, da so oft per Unfall ein Objekt gelöscht wird, welches an anderer Stelle noch gebraucht wird.
Manuelle Speicherverwaltung wird nur noch sehr selten verwendet. Boost bietet seit langem Smart-Pointer, seit C++11 sind diese sogar in die Standardbibliothek übergegangen. Bei zyklischen Referenzen muss man ggf. Weak-Pointer einsetzen, das kommt aber eher selten vor. Der Vorteil ist eben, dass man sich selbst um den Speicher kümmern kannn, wenn man das muss. Es gibt eben Situationen, in denen vollständige Kontrolle über den Speicher benötigt wird, bzw. auch darüber, wie und wann dieser freigegeben wird. In Echtzeitumgebungen geht es zum Beispiel gar nicht anders und auch in performancekritischen Anwendungen wird man um einige Dinge nicht herumkommen. Wird das alles nicht benötigt, dann muss man auf der Ebene auch nicht arbeiten, aber dann ist mit der Wahl der Sprache für das Projekt schon einen Fehler gemacht worden.
Das Leben ist wie ein Tennisball.
BlackJack

@EyDu: Wenn ich mich aktiv darum kümmern muss Smartpointer zu verwenden und mir Gedanken darüber machen muss ob so einer in der jeweiligen Situation funktioniert oder ich doch etwas anderes brauche, dann ist das für mich immer noch manuelle Speicherverwaltung.
Benutzeravatar
bwbg
User
Beiträge: 407
Registriert: Mittwoch 23. Januar 2008, 13:35

Die Überlegung nimmt Dir in Python auch keiner ab. Auch hier musst Du überlegen, wem die Objekte gehören und ggf. eine weak-reference verwenden.

Python verwendet so gesehen das Analog zu C++11 std::shared_ptr und std::weak_ptr. Lediglich der std::unique_ptr käme noch dazu.

Aber ja, C++* ist schon schwer komplex. Nun sind noch lambdas, move-semantics, for-each, etc. hinzugekommen mit dem Anspruch, dass die Compiler weiterhin mit dem alten Standard und noch mit altem Code zurecht kommen.

Wenn ich dann an eine templated pointer reference für ein Array denke ... hat man schon fast Perl-Code :-D
"Du bist der Messias! Und ich muss es wissen, denn ich bin schon einigen gefolgt!"
BlackJack

@bwbg: Natürlich nimmt mir diese Überlegungen in Python die automatische Speicherbereinigung ab. Wo muss ich denn da im allgemeinen über so Sachen wie „wer besitzt das Objekt” oder `weakref` nachdenken? Das ”musste” ich in all den Jahren nur ein einziges mal in reinem Python machen, aus Performancegründen, und sonst nur wenn ich externe C-Bibliotheken mit `ctypes` angebunden habe, also mir sowieso schon Gedanken über Speicherverwaltung machen musste wegen dem C-Code. Beides sind keine alltäglichen Fälle. Jedenfalls nicht für die Mehrzahl der Python-Programmierer und schon gar nicht für Programmieranfänger.
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

bwbg hat geschrieben:Die Überlegung nimmt Dir in Python auch keiner ab.
Nö, denn ich habe in Python quasi keine Wahl ;-) Und das ist auch gut so!
bwbg hat geschrieben: Auch hier musst Du überlegen, wem die Objekte gehören und ggf. eine weak-reference verwenden.
Das ist ein absoluter Spezialfall; dies ist alleine daran kenntlich, dass das ganze in einem separaten Modul verpackt ist und mithin kein Konstrukt auf Sprachebene dazu existiert.
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
EyDu
User
Beiträge: 4881
Registriert: Donnerstag 20. Juli 2006, 23:06
Wohnort: Berlin

@BlackJack: Es ist jetzt wirklich nicht so schwer sich daran zu erinnern, dass man bei einem new-Aufruf alles in einen Smart-Pointer packt. ;-) Ich kann mich nicht daran erinnern, dass ich das jemals vergessen hätte.

Prinzipiell bleiben auch nur zwei Möglichkeiten übrigen, wenn manuelle Speicherverwaltung zugelassen werden soll: 1) Default ist, dass das Objekt vom GC/automatisch über Smart-Pointer verwaltet wird und manuelle Speicherverwaltung explizit angegeben werden muss oder 2) eben genau anders herum. Was in einer Sprache gewählt wird, dass hängt vom Einsatzgebiet der Sprache ab. Mir ist eben der zweite Punkt wichtig, da ich im Normalfall die Kontrolle brauche.
Das Leben ist wie ein Tennisball.
Antworten