vergesst C++ ...

[Power Off]

Ben04 schrieb:

lol Mal darüber nachgedacht wie sich ein Objekt denn Abmelden soll wenn es keine Destruktoren gibt? Ein GC funktioniert nicht nach dem Prinzip, dass sich Objekt anmelden und abmelden sondern, dass sie sich melden oder besser, dass sie gemeldet werden. Der Stack meldet sämtlich Objekt auf ihm.

Wie wär's Du lernst erstmal C++ richtig, bevor Du solche Behauptungen aufstellst.

Objekte für einen GC werden meist mit Placement-new und -delete erzeugt, sowie natürlich im Konstruktor und virtuellen Destruktor registriert / deregistriert. Solche Objekte müssen von einer virtuellen Basisklasse abgeleitet werden (z.B. "GC_Object"), die die Implementation für Placement-new und -delete sowie den passenden Konstruktor und Destruktor, sowie Copy-Construktor und Copy-Assignment mitbringt.

Selbstverständlich müssen sich Objekte direkt oder indirekt am GC anmelden, damit er weiß, welche Objekte wo sind.

So funktioniert auch die Absicherung für Multithread-GCs.

[Gast]

Power Off schrieb:

Kommt darauf an, wieviel Objekte Du hast. Schätz mal, warum JBuilder oder Eclipse so lahm sind. Importier mal ein Real-Life Projekt (z.B. ein Framework mit 3000-6000 Java-Klassen) in JBuilder, und dann kannst Du Dir Kaffee und Kuchen, sowie Zigaretten nebendran stellen.

Hmmmm also beim Starten von Eclipse geht bei mir eine halbe Sekunde mit garbage collection drauf. Das ist zwar wesentlich mehr als ich erwartet hatte, macht aber prozentual bei einem Warmstart höchstes ein Zehntels aus, bei einem Kaltstart mit ständigem Festplattenzugriff natürlich noch weniger. Wo genau soll Eclipse wegen GC langsam sein?

Das ist nicht die Aufgabe des Java-Programmierers, seine Programme auf die GC hin zu designen, da ja der GC transparent sein soll.

Dann gehen wir doch von einem Java-Entwickler aus, der seine Anwendung nicht auf den GC hin optimiert. Der ist meistens besser dran, wie einer, der einen klassischen Heap benutzt und auch nicht spezielle Allokatoren für seine Anwendung schreibt. Der Vorteil manueller Speicherverwaltung kommt nur zum Tragen, wenn man spezielle für das Anwendungsprofil angepasste Allokatoren schreibt.

Selbstverständlich müssen sich Objekte direkt oder indirekt am GC anmelden, damit er weiß, welche Objekte wo sind.

Das ist so nicht völlig korrekt. Objekte melden sich für die Finalisierung an (im Falle von Java heißt das, falls die Klasse java.lang.Object.finalize() redefiniert). Das sind die wenigsten.

Objekte für einen GC werden meist mit Placement-new und -delete erzeugt

Zusammen mit der obigen Aussage komme ich zu dem Schluss, dass du dir nicht darüber im klaren bist, wie ein kopierender Kollektor arbeitet. Ein kopierender Kollektor muss gar nichts über die Objekte wissen und sowas wie delete braucht er nicht, weil er referenzierte Objekte verschiebt und über den anderen Speicher einfach darüber allokiert. Warum siehst du dir nicht zur Abwechslung mal die von mir verlinkten Artikel an oder suchst dir selber welche heraus?

[Power Off]

Optimizer schrieb:

Warum siehst du dir nicht zur Abwechslung mal die von mir verlinkten Artikel an oder suchst dir selber welche heraus?

OK, mach ich -- morgen!

Das Thema interessiert mich.

Aber ich finde, dass delete und Destruktoren auf jeden Fall bei C++ dazugehoeren. Sonst sind die Probleme ja nicht weiter verwunderlich.

[kartoffelsack]

Und wenn es doch ginge,
gäbe es keine Standard-Collection für C++ und damit wären Klassen nicht mehr
zwengsläufig untereinander kompatibel, wenn sie auf verschiedenen
Collection-Mechanismen angewiesen sind.

Das ist in C++/CLI meines wissens auch so. Entweder GC oder new. Mach die Sache natürlich noch komplexer.

Wenn die simple Aufgabe, einen Speicherbereicht sicher zu belegen und
vor allem sicher wieder freizugeben, mehr als 1500 Seiten Lektüre erfordert,
dann -- da werden wir uns doch einig sein -- stimmt mit einer solchen
Programmiersprache didaktisch und womöglich konzeptuell etwas ganz entschieden nicht.

Es ist definitiv ein didaktisches Problem. 90% aller Bücher für einsteiger behandeln char* und Zeigerarithmetik in zig Kapiteln und erst ganz am Schluss findest Du vielleicht etwas über std::string (aber das schein mit neueren Büchern ja jetzt langsam besser zu werden). std::auto_ptr ist auch kein allgemein einsetzbarer Smartpointer. D.h. einfach wird es erst, wenn man sich mal boost geholt hat. Das ist natürlich ne Rieserhürde. Und selbst wenn man das alles toll richtig installiert und compiliert nach der Installation der IDE Deiner Wahl da wäre, bin ich mir immer noch nicht sicher, ob mans nem Anfänger empfehlen kann. Zwar ist es prinzipiell einfach schön und elegant. Aber kleine Fehler führen zu völlig kryptischen Compilerfehlern ...
Und wenn man dann schon mal ein bisschen was kann, brauch man immer noch ewig, nur um sich ne Bibliothek zu suchen, wenn man was über UDP verschicken will ...

Wars Volkard oder Marc++us der mal gemeint hat, dass die c++-Comunity so lang gebraucht hat, die Templates zu kapieren, dass sie alles andere vergessen haben.

Naja, aber wenn man C++ mal ein bisschen kann, naja, dann ist es schon viel geiler als andere Sprachen und ich denk man ist durch die besseren Ausdrucksmöglichkeiten langfristig auch produktiver (die gewonnene Zeit verbringt man aber beim Suchen nach irgendwelchen soap, xml oder GUI-Bibliotheken). Ist halt ein steiniger Weg.

[maximAL]

groovemaster schrieb:

So hat halt jede Sprache ihre Vor- und Nachteile und damit ihre Einsatzgebiete. Hast du schon mal versucht, mit Python einen Emulator zu schreiben?

gut, dass das noch kommt, nachdem man seitenlang alles getan hat um klar zu machen, das C++ eh alles kann, nur natürlich viel besser.
schön auch das obligatorische low-level beispiel.

[groovemaster]

maximAL schrieb:

gut, dass das noch kommt, nachdem man seitenlang alles getan hat um klar zu machen, das C++ eh alles kann, nur natürlich viel besser.

Ich wüsste nicht, dass das jemand getan hat, wobei ich nicht jeden Beitrag bis ins Detail gelesen habe. Lediglich das Orakel versucht hier mit Python die Weltherrschaft an sich zu reissen.

[O'Rakl]

<Naja, aber wenn man C++ mal ein bisschen kann, naja, dann ist es schon viel geiler als andere Sprachen><

Meinst Du wirklich ? Wenn man C++ ein bischen kann, ist es eher eine
Katastrophe, weil man dann ständig mit Compiler-Errors zu tun bekommt, die
nichts über die Fehlerursache sagen und kommentarlose Abstürze beim Testlauf.

Um Spaß mit C++ zu haben, muß man es *richtig* können, man muß wissen, wie
der Compiler intern funktioniert, man muß etliche Bibliotheken kennen, nur um
mal ein absturzsicheres Array benutzen zu können, man muß wissen, wieviel und
was der Compiler auf den Stack packt und anhanddessen auswählen, ob man Daten
const deklariert, um keinen Stacküberlauf zu riskieren, usw...
-- alles Dinge, mit denen man als Programmierer nach 50 Jahren der
Programmiersprachen-Evolution nicht mehr konfrontiert werden will.

<und ich denk man ist durch die besseren Ausdrucksmöglichkeiten langfristig auch produktiver><

Die Ausdrucksmöglichkeiten an abstrakteren Konzepten als Bit, Byte und
Pointer von C++ sind im Vergleich mit Python nahezu
Null. Deshalb sind C++-Programme ja auch so lang.

[volkard]

O'Rakl schrieb:

Um Spaß mit C++ zu haben, muß man es *richtig* können, man muß wissen, wie der Compiler intern funktioniert, man muß etliche Bibliotheken kennen, nur um mal ein absturzsicheres Array benutzen zu können, man muß wissen, wieviel und was der Compiler auf den Stack packt und anhanddessen auswählen, ob man Daten const deklariert, um keinen Stacküberlauf zu riskieren, usw...

ok, du hast keinen schimmer von c++- wie du hier beweisen tust.

soll ich die jetzt deswegen glauben, daß python gut ist? eher nicht. logischerweise nehm ich erstmal an, daß du python auch nicht gut kennst.
ich wart doch lieber, bis einer, dem ich vertrauen kann, sich dazu äußert.

Die Ausdrucksmöglichkeiten an abstrakteren Konzepten als Bit, Byte und
Pointer von C++ sind im Vergleich mit Python nahezu
Null. Deshalb sind C++-Programme ja auch so lang.

mach nicht c++ schlecht mit argumenten, die nur auf c und nicht auf c++ zutreffen.

[GPC]

Um Spaß mit C++ zu haben, muß man es *richtig* können,

Bollocks, man muss nicht jedes Detail können um "Spaß" mit C++ zu haben, aber wenn man sich richtig gut auskennt, dann kommt imho richtig geile Software dabei raus. Tu bloß nicht so als wäre man nach kurzem Durchlesen des Python Tuts der Leibhaftige auf Erden.

Noch was zu Python: Mir geht die Syntax auf den Sack, ich will meine verdammten Zeilen mit nem Semikolon beenden und meine Funktionen und Klassen mit geschweiften Klammern auf - und zumachen!

[O'Rakl]

volkard:

<<ich wart doch lieber, bis einer, dem ich vertrauen kann, sich dazu äußert.>>

Sorry, ich wollte niemandem auf die Füße treten. Ich mein's doch nur gut

<<mach nicht c++ schlecht mit argumenten, die nur auf c und nicht auf c++ zutreffen.>>

Wieso ? Was kann denn C++ von sich aus mehr als Bits, Bytes, Arithmetik
(natürlich nicht mit langen Zahlen) und Pointer ? Für s="hello world\n" muss man schon eine Bibliothek bemühen.
ZX81-BASIC konnte das ja noch.

Zeig' mal, wie Du die Liste
L=["hallo","python", 2.4, "ist cool"]
in C++ programmierst.

Ich denke schon, daß C++ im Vergleich mit Ruby oder Python nicht besonders
ausdrucksstark ist. Das zeigt doch die Umständlichkeit im Umgang mit Strings, Listen und Maps recht deutlich.

[volkard]

GPC schrieb:

Noch was zu Python: Mir geht die Syntax auf den Sack, ich will meine verdammten Zeilen mit nem Semikolon beenden und meine Funktionen und Klassen mit geschweiften Klammern auf - und zumachen!

das geht mir ganz anders.
seitdem ich python "kann", will ich in c++ keine semikolons und geschweiften klammern mehr setzen, sindern nur durch einrücken die blöcke bestimmen.

[Sovok]

O'Rakl schrieb:

Zeig' mal, wie Du die Liste
L=["hallo","python", 2.4, "ist cool"]
in C++ programmierst.

char* sBuffer [] = { "hallo", "python", "2.4", "ist cool" };

und wenn du den double haben sillt kannst ihn ja konvertiern

double dValue = atof ( sBuffer[2] );

[kartoffelsack]

@oracle
was spricht gegen Bibliothen? Mir ist das prinzipiell wurscht, ob ich die ausgabe mit ner Bibliothek oder mit was intrinsischem mache. Bibliotheken haben halt den Vorteil, dass sie anpassbarer sind, dass sie nicht nur vom Compilerhersteller kommen können ... . Und in c++ kann man sehr gute Bibliotheken schreiben. Nur leider gibts halt nix, wass man mit der Java-Standardbibliothek (oder Python) vergleichen kann (vom Umfang, was es gibt, ist von der Qualität z.T. sehr viel besser).

Ich denke schon, daß C++ im Vergleich mit Ruby oder Python nicht besonders
ausdrucksstark ist. Das zeigt doch die Umständlichkeit im Umgang mit Strings, Listen und Maps recht deutlich.

Was ist an std::map, std::list etc umständlich? Was an std::string??? Bei den Containern vielleicht, dass man es nicht in einer Zeile mit mehreren Objekten füllen kann? Ok, aber das hat nicht so viel mit Ausdrucksstärke zu tun, braucht man eigentlich in realen Projekten selten ('nur' in Testcode) und funzt außerdem. Mit Bibliotheken! http://www.boost.org/libs/assign/doc/index.html

Die Fehlermeldungen bei der Verwendung dieser Bibliothen sind aber wirklich so, dass man sie einem Anfänger fast nicht empfehlen kann. Obwohl sie einfach genug handzuhaben wären

[Power Off]

O'Rakl schrieb:

Wieso ? Was kann denn C++ von sich aus mehr als Bits, Bytes, Arithmetik
(natürlich nicht mit langen Zahlen) und Pointer ?

Referenzen, Datenstrukturen, Datenvereinigung, Klassen, Schablonen-Klassen, Schablonen-Funktionen, Ausnahmebehandlung, Mehrfachvererbung, usw.

O'Rakl schrieb:

Für s="hello world\n" muss man schon eine Bibliothek bemühen.
ZX81-BASIC konnte das ja noch.

Ja, im Prinzip hast Du Recht -- aber spielt das wirklich so 'ne große Rolle, ob Du erst ein Include machen mußt oder nicht? Bei Java muß man ja auch erst "import" machen.

#include <string>

using std::string;

string h = "hello world\n";

Ich hab vor Jahren auch schon mal versucht, einen Vorschlag fürs ANSI C++ Kommittee einzureichen (über comp.lang.c++), aber ich wurde bombardiert mit Statements wie "dafür braucht man keine Spracherweiterung, weil's ja die STL gibt". Aber es ist nicht von der Hand zu weisen, daß eingebaute Features wie

- Strings
- Containerklassen wie Listen, Vektoren, Maps, etc.
- Array-Bounds-Checking (und Konfiguration)

sinnvolle Spracherweiterungen wären, die es dem Compiler ermöglichen würden, mehr zu optimieren als bei der Verwendung von Template-Klassen.

Heutzutage könnte man auch noch GUI-, Konsolen-, Multithread-, Netzwerk- Programmierelemente mit in die Sprache aufnehmen, weil sie so häufig vorkommen. Und sie könnten z.B. optional sein, so daß der Embedded Bereich nicht auf C++ verzichten muß.

Für die vielen Ideen, die ich für C++ hatte, muß ich irgendwann mal einen Referenz-C++ Compiler schreiben, damit ich die Vorzüge davon demonstrieren kann.

Template-Klassen sind zwar ganz nett, aber wie Du richtig erkannt hast, ist die Verwendung davon weitaus aufwendiger als in anderen Sprachen.

Die bloße Tipparbeit kann sich nämlich schnell summieren, und man hält sich mit endloser Tipperei auf; Ich verwende oft "typedef", um Aliase für Template-Instanzen zu definieren, damit ich weniger tippen muß.

Ich bin auch ein Verfechter einfacher Programmierschnittstellen.

Vielleicht sollte man mal eine neue, C++ ähnliche, Sprache entwickeln, die alle Features hat, die man so braucht. Und zwar als Compiler-Sprache, die in ausführbare Programme übersetzt wird. Was mich bei Perl, PHP und Python nervt, ist daß ich dafür immer einen extra Interpreter brauche. (Es gibt auch Compiler für Perl z.B., aber leider nicht für umme)

O'Rakl schrieb:

Zeig' mal, wie Du die Liste
L=["hallo","python", 2.4, "ist cool"]
in C++ programmierst.

C++ hat den Nachteil, daß es z.B. keine Initialisierung von Objekt-Arrays gibt. Schwerer Design-Fehler, m.E.

Auch ist es nicht möglich, z.B. benutzerdefinierte Notationen zu machen. Operator-Overloading ist zwar ganz nett, aber geht bei weitem noch nicht weit genug.

Dein Beispiel würde in C++ ca. 100 Programmzeilen erfordern, weil man erst noch eine virtuelle Basisklasse und davon abgeleitete Spezialisierungen für double und string machen muß, bevor man das Zeug in eine Liste schieben kann. Das Problem ist, daß es bei Templates keine dynamische bzw. kontextabhängige Typisierung gibt.

D.h. ich kann nicht dieselbe Template-Instanz (von list z.B.) für zwei verschiedene Objekttypen benutzen, außer, die Objekttypen basieren auf derselben Basisklasse.

Da ist z.B. Java besser dran, da ausnahmslos alle Datentypen von der Klasse Object abgeleitet sind. Wenn das in C++ auch so wäre, könnte man Templates machen, die Object als Parameter haben.

[volkard]

Power Off schrieb:

Aber es ist nicht von der Hand zu weisen, daß eingebaute Features wie
- Strings
- Containerklassen wie Listen, Vektoren, Maps, etc.
- Array-Bounds-Checking (und Konfiguration)
sinnvolle Spracherweiterungen wären, die es dem Compiler ermöglichen würden, mehr zu optimieren als bei der Verwendung von Template-Klassen.

doch, klar. ich weise es hiermit von der hand.
einbauen von strings bringt doch mal wirklich gar nix.
containerklassen? wozu als sprachmittel?
array-bounds-checking haben wir doch bereits.

Für die vielen Ideen, die ich für C++ hatte, muß ich irgendwann mal einen Referenz-C++ Compiler schreiben, damit ich die Vorzüge davon demonstrieren kann.

ja, mach das mal.

Die bloße Tipparbeit kann sich nämlich schnell summieren, und man hält sich mit endloser Tipperei auf; Ich verwende oft "typedef", um Aliase für Template-Instanzen zu definieren, damit ich weniger tippen muß.

eih, das ist ne tolle idee. daß ich da nicht von alleine drauf gekommen bin! uih uih uih.

Ich bin auch ein Verfechter einfacher Programmierschnittstellen.

ich nicht. was sind nochmal schnittstellen?

Vielleicht sollte man mal eine neue, C++ ähnliche, Sprache entwickeln, die alle Features hat, die man so braucht.

also garbage-collection, strings als sprachmittel, eingebaute container, whitespace-overloading, range-checking, optionale sockets, threads und gui als sprachmittel, reflection und objektpersistenz.

(Es gibt auch Compiler für Perl z.B., aber leider nicht für umme)

ein prog, das den perl-compiler und den code in eine exe-datei knallt? jo, hab ich schon benutzt.

Dein Beispiel würde in C++ ca. 100 Programmzeilen erfordern, weil man erst noch eine virtuelle Basisklasse und davon abgeleitete Spezialisierungen für double und string machen muß, bevor man das Zeug in eine Liste schieben kann. Das Problem ist, daß es bei Templates keine dynamische bzw. kontextabhängige Typisierung gibt.

D.h. ich kann nicht dieselbe Template-Instanz (von list z.B.) für zwei verschiedene Objekttypen benutzen, außer, die Objekttypen basieren auf derselben Basisklasse.

Da ist z.B. Java besser dran, da ausnahmslos alle Datentypen von der Klasse Object abgeleitet sind. Wenn das in C++ auch so wäre, könnte man Templates machen, die Object als Parameter haben.

wirst bestimmt ne lib im netz finden, die dir wie in java auch Int und Double (beide erben von Object) anbietet.

[maximAL]

groovemaster schrieb:

maximAL schrieb:

gut, dass das noch kommt, nachdem man seitenlang alles getan hat um klar zu machen, das C++ eh alles kann, nur natürlich viel besser.

Ich wüsste nicht, dass das jemand getan hat, wobei ich nicht jeden Beitrag bis ins Detail gelesen habe.

oh doch, genau darum geht es hier.

und wer ernsthaft den standpunkt vertritt, dass C++ ein ebenso hohes abstraktionsniveau wie andere, höhere spachen hat (speziell python kenn ich nicht) und sich grundsätzlich alle probleme ebenso leicht lösen lassen (natürlich, mit lib xyz und wenn man weiss wie etc. pp. ist sowieso alles möglich), der hat entweder
- gar keinen plan
oder
- ein verflucht großes brett vorm kopf

absolut diskussionsunwürdiges thema.

[kartoffelsack]

O'Rakl schrieb:

Zeig' mal, wie Du die Liste
L=["hallo","python", 2.4, "ist cool"]
in C++ programmierst.

C/C++ Code:
char* sBuffer [] = { "hallo", "python", "2.4", "ist cool" };
C/C++ Code:
char* sBuffer [] = { "hallo", "python", "2.4", "ist cool" };

Der vorgeschlagene Code ist C, nicht c++!

#include <list>
#include <boost/assign/list_of.hpp> // for 'list_of()'
#include <boost/any.hpp>
#include <boost/variant.hpp>

using namespace std;
using namespace boost;
using namespace boost::assign; // bring 'list_of()' into scope

list<any> l = list_of( any( string("hallo")))
                     ( any( string("python")))
                     ( any(2.4))
                     ( any( string( "ist cool")));

Ich geb zu, ich hatte auch nicht erwartet, dass ich überall explizit string und any angeben muss, deswegen musst ich ein bisschen rumprobieren (habs in der Kombination noch nie benutzt (wann braucht man sowas in realen Projekten? Normalerweise nur in Tescode). Das wär in Python aufs erste mal schneller gegangen. Punkt ist aber, dass C++ mit Bibliothen dieselbe Ausdruckskraft erreicht, wie andere Sprachen über eingebaute Sachen. Und da man nicht alles einbauen kann ist C++ mE ausdrucksstärker. Dass das nicht so schnell zu haben ist, hat keiner bestritten.

[Sovok]

maximAL schrieb:

und wer ernsthaft den standpunkt vertritt, dass C++ ein ebenso hohes abstraktionsniveau wie andere, höhere spachen hat (speziell python kenn ich nicht) und sich grundsätzlich alle probleme ebenso leicht lösen lassen (natürlich, mit lib xyz und wenn man weiss wie etc. pp. ist sowieso alles möglich), der hat entweder
- gar keinen plan
oder
- ein verflucht großes brett vorm kopf

absolut diskussionsunwürdiges thema.

nö ich mag c/c++ besonders weil keine andere sprache lowlvl und highlvl so gut verknüpft und dem entwickler überlässt wie abstrakt oder hardwarenah er arbeiten will

abgesehn davon hängts vom problem ab welche sprache am geeignetsten is... der rest is unnütze verallgemeinerung

[Sovok]

kartoffelsack schrieb:

O'Rakl schrieb:

Zeig' mal, wie Du die Liste
L=["hallo","python", 2.4, "ist cool"]
in C++ programmierst.

C/C++ Code:
char* sBuffer [] = { "hallo", "python", "2.4", "ist cool" };
C/C++ Code:
char* sBuffer [] = { "hallo", "python", "2.4", "ist cool" };

Der vorgeschlagene Code ist C, nicht c++!

#include <list>
#include <boost/assign/list_of.hpp> // for 'list_of()'
#include <boost/any.hpp>
#include <boost/variant.hpp>

using namespace std;
using namespace boost;
using namespace boost::assign; // bring 'list_of()' into scope

list<any> l = list_of( any( string("hallo")))
                     ( any( string("python")))
                     ( any(2.4))
                     ( any( string( "ist cool")));

Ich geb zu, ich hatte auch nicht erwartet, dass ich überall explizit string und any angeben muss, deswegen musst ich ein bisschen rumprobieren (habs in der Kombination noch nie benutzt (wann braucht man sowas in realen Projekten? Normalerweise nur in Tescode). Das wär in Python aufs erste mal schneller gegangen. Punkt ist aber, dass C++ mit Bibliothen dieselbe Ausdruckskraft erreicht, wie andere Sprachen über eingebaute Sachen. Und da man nicht alles einbauen kann ist C++ mE ausdrucksstärker. Dass das nicht so schnell zu haben ist, hat keiner bestritten.

die c syntax gehört zu c++ und somit is es standard c++ code
dein boost zeug hingegen gehört ( noch? ) nich zum standard

sonst könnt ich ja auch mit irgendwelchen m$ variant datentypen ankommen

[kartoffelsack]

Dein Beispiel würde in C++ ca. 100 Programmzeilen erfordern, weil man erst noch eine virtuelle Basisklasse und davon abgeleitete Spezialisierungen für double und string machen muß, bevor man das Zeug in eine Liste schieben kann. Das Problem ist, daß es bei Templates keine dynamische bzw. kontextabhängige Typisierung gibt.

D.h. ich kann nicht dieselbe Template-Instanz (von list z.B.) für zwei verschiedene Objekttypen benutzen, außer, die Objekttypen basieren auf derselben Basisklasse.

völlig falsch. s.o.

Auch ist es nicht möglich, z.B. benutzerdefinierte Notationen zu machen.

was meinst Du damit?

und wer ernsthaft den standpunkt vertritt, dass C++ ein ebenso hohes abstraktionsniveau wie andere, höhere spachen hat (speziell python kenn ich nicht) und sich grundsätzlich alle probleme ebenso leicht lösen lassen (natürlich, mit lib xyz und wenn man weiss wie etc. pp. ist sowieso alles möglich), der hat entweder
- gar keinen plan
oder
- ein verflucht großes brett vorm ko

Behaupte ich. Unterstützt sogar höhere Abstraktionsschema also so manche andere Sprachen (policy-based-Design, z.B.). In C++ kannst Du das Abstraktionsschema frei wählen von sehr niedrig bis sehr hoch. Das ist einer der Gründe, warum C++ so schwer ist. Gleichzeitig aber auch so mächtig. Du hast den ganzen Platz, nicht nur ne Strecke mit Bande. Deswegen ist C++ auch eine Sprache die sich für (fast) alles eignet (wenn man jetzt von ganz anderen Ansätzen wie funktionalem Programmieren etc. absieht).