vergesst C++ ...

Sovok

Redhead schrieb:

Ich habs ja immer gewusst. Meyers, Sutter, Alexandrescu, Stroustrup go home.
Der erste perfekte C++ Programmierer sitzt hier.

ne das nich aber recht hat er
oder solln wir demnächst wie bei vb anfangen jedem array n zusätzliches element zu geben nur damits egal is ob man mit index 0 oder 1 anfängt... wasn unsinn

GPC

TactX schrieb:

Ich dachte ja immer, dass Ruby jetzt "Everybody's Darling" ist

Hm, wenn man sich die OO Fähigeiten ansieht kann man sich eigentlich schwer vorstellen, warum die Scripting-Gemeinde davon Abstand hält??

volkard

Redhead schrieb:

Ich habs ja immer gewusst. Meyers, Sutter, Alexandrescu, Stroustrup go home.
Der erste perfekte C++ Programmierer sitzt hier.

hat nix mit perfektion zu tun. einfach "effektiv c++ programmieren" von meyers lesen und ein wenig üben und du machst auch keine fehler mehr bei freigaben, löschungen und konstruktoren.

volkard schrieb:

Redhead schrieb:

Ich habs ja immer gewusst. Meyers, Sutter, Alexandrescu, Stroustrup go home.
Der erste perfekte C++ Programmierer sitzt hier.

hat nix mit perfektion zu tun. einfach "effektiv c++ programmieren" von meyers lesen und ein wenig üben und du machst auch keine fehler mehr bei freigaben, löschungen und konstruktoren.

Wer keine Fehler macht ist perfekt. Das ist nun mal, meines Wissens, die Bedeutung
von perfekt, in diesem Zusammenhang.
Keinen Einspruch hätte ich erhoben wenn du geschrieben hättest:
...weniger/seltener/kaum noch...Fehler mehr bei..."

volkard schrieb:

ich mach da aber keine fehler und mag c++.
und ich werde nicht zu einer anfängersprache umsteigen, nur weil du lernschwach bist.

Du wirst aufgrund Deiner langjährigen intensiven C++-Exposition sozusagen
Teil des Compilers, sodaß Du gar nicht mehr merkst, wieviel Arbeit Du für diesen mitmachst. Der C++-Compiler läßt es dagegen gemütlich angehen, gibt dann und
wann mal eine Fehlermeldung, oft ohne wirklich auf die Zeile zu verweisen, an
der der Fehler eigentlich ist -- wozu gibt es schließlich Debugger ?

Nach einigen Jahren beginnt man es dann allmählich für normal zu halten, die
Garbage Collection und Speicherverwaltung in jedem Programm aufs Neue selbst zu organisieren (,was sicher nicht effizienter ist als eine festeingebaute GC,
die auf Erkenntnissen beruht, die GC-Spezialisten in Jahrzehnten der Forschungsarbeit gewonnen haben...) und hält dann *andere* Sprachen -- solche,
die zumindest einen minimalen Programmierkomfort wie festeingebaute Datentypen
Liste, Strings etc.. und automatische Speicherverwaltung -- besitzen, für
komisch oder "irgendwie für Anfänger" zu halten.

Die Zukunft gehört Sprachen mit GC, mit automatischer Speicherverwaltung
und wahrscheinlich mit irgendeiner Art Bytecode. C kann man dann ja immer
noch verwenden, um dann und wann eine zeitkritische Unterroutine zu optimieren
oder einen Hardwaretreiber zu schreiben.

Walli

O'Rakl schrieb:

Die Zukunft gehört Sprachen mit GC, mit automatischer Speicherverwaltung und wahrscheinlich mit irgendeiner Art Bytecode.

Du meinst C++/CLI?

Walli schrieb:

Du meinst C++/CLI?

Ja, genau ( -- Hääääääääh ?? )

volkard

O'Rakl schrieb:

Du wirst aufgrund Deiner langjährigen intensiven C++-Exposition sozusagen Teil des Compilers, sodaß Du gar nicht mehr merkst, wieviel Arbeit Du für diesen mitmachst. Der C++-Compiler läßt es dagegen gemütlich angehen, gibt dann und wann mal eine Fehlermeldung, oft ohne wirklich auf die Zeile zu verweisen, an der der Fehler eigentlich ist -- wozu gibt es schließlich Debugger ?

ich hab jetzt 18 monate lang c++ geschrieben ohne verwendung eines debuggers. hab ich nicht erzählt, daß man durch feinen c++-stil viele laufzeitfehler vermeidet, indem man solche kostrukte schreibt, die compilerfehler machen oder wenigstens sehr zuverlässige und deutliche laufzeitfehler?
speicherlöcher mach ich auch, aber nur zwei pro jahr.

Nach einigen Jahren beginnt man es dann allmählich für normal zu halten, die Garbage Collection und Speicherverwaltung in jedem Programm aufs Neue selbst zu organisieren

di containerklassen räumen doch fein auf. noch ein wenig sutter lesen und sich exceptionsicheren code angwöhnen, und fertig ist der lack.

(,was sicher nicht effizienter ist als eine festeingebaute GC,
die auf Erkenntnissen beruht, die GC-Spezialisten in Jahrzehnten der Forschungsarbeit gewonnen haben...)

wenn irgend möglich, halte ich meine daten auf dem stack und das ist natürlich noch schneller. und ansonsten wird halt vom dtor aufgeräumt. genau zum richtigen zeitpunkt. wie dann die operator delete implemetiert ist, ist frei. gerne mit verzögerter freigabe, threadlokalen freispeicherlisten und allem, was die gc-spezielisten an schnellen sachen für's memory-management erfunden haben. nur der gc selber tut nicht not.

und hält dann *andere* Sprachen -- solche, die zumindest einen minimalen Programmierkomfort wie festeingebaute Datentypen Liste, Strings etc.. und automatische Speicherverwaltung -- besitzen, für komisch oder "irgendwie für Anfänger" zu halten.

"irgendwie für Anfänger" ist der logische schluß, weil du so begründest, warum du c++ nicht magst.

Die Zukunft gehört Sprachen mit GC, mit automatischer Speicherverwaltung
und wahrscheinlich mit irgendeiner Art Bytecode. C kann man dann ja immer
noch verwenden, um dann und wann eine zeitkritische Unterroutine zu optimieren
oder einen Hardwaretreiber zu schreiben.

die zukunft gehört auch mikrowellenherden mit dem aufkleber "bitte keine lebenden tiere reintun, die gehen schnell tot beim erwärmen." aber wer braucht sowas?

volkard schrieb:

hab ich nicht erzählt, daß man durch feinen c++-stil viele laufzeitfehler vermeidet, indem man solche kostrukte schreibt, die compilerfehler machen oder wenigstens sehr zuverlässige und deutliche laufzeitfehler?

Super. Man schreibt also (C++)--Code (hoffe, die Klammerung verwirrt nicht,
aber "C++--Code" wäre ja gleich "C Code"), der es, wenn er abstürzt, so richtig krachen läßt, am besten gleich mit Reboot, damit man den Fehler schneller bemerkt. Daß der Compiler von sich aus auf
die fehlerhafte Zeile verweist (bei Python der Normalfall), wird gar nicht
mehr ernsthaft als Möglichkeit erwogen.

Ben04

O'Rakl schrieb:

Eben, das ist aber das Problem. Bei C++ kann Dir nie *irgendetwas* egal sein, weil Du Dich um tausend Dinge selbst kümmern mußt, die eigentlich Aufgabe des Compilers und der Runtime-Umgebung sind (Zeigerarithmetik, Referenzen, Speicherverwaltung, Objekte löschen ...)

Ein Objekt als Argument an eine Funktion übergeben ? Haha, reingefallen.
Hättest halt erst den Copy-Konstruktor überladen müssen
Speicher zweimal freigegeben ? Pass doch auf, wann Du Objekte löschst, Dummerchen

Wenn du mir zeigen kannst wo ich bei std::vector, boost::ptr_vector, boost::shared_ptr, boost::scoped_ptr oder bei std::string selbst um Kopiekonstruktor oder new/delete kümmern muß dann wechsele ich zu Python.

O'Rakl schrieb:

Nach einigen Jahren beginnt man es dann allmählich für normal zu halten, die Garbage Collection und Speicherverwaltung in jedem Programm aufs Neue selbst zu organisieren

Wenn man zu blöd ist STL/Boost oder ähnliches zu benutzen dann hast du recht. Das sind aber meist nur Leute die C++ aus religieusen Gründen schlecht machen wollen indem sie Möglichkeiten als Zwangsmittel verkaufen wollen.

O'Rakl schrieb:

volkard schrieb:

hab ich nicht erzählt, daß man durch feinen c++-stil viele laufzeitfehler vermeidet, indem man solche kostrukte schreibt, die compilerfehler machen oder wenigstens sehr zuverlässige und deutliche laufzeitfehler?

Super. Man schreibt also (C++)--Code (hoffe, die Klammerung verwirrt nicht,
aber "C++--Code" wäre ja gleich "C Code"), der es, wenn er abstürzt, so richtig krachen läßt, am besten gleich mit Reboot, damit man den Fehler schneller bemerkt.

zuverlässig und deutlich ist zum beispiel, wenn man range-checked iteratoren benutzt, die ASSERT benutzen oder exceptions werfen.

Daß der Compiler von sich aus auf die fehlerhafte Zeile verweist (bei Python der Normalfall), wird gar nicht mehr ernsthaft als Möglichkeit erwogen.

ähm, das hab ich vor jahren schon für c++ gebaut. einfach ein "__asm int 3" ins ASSERT rein und beim fehler geht der debugger auf und zeigt einem genau die zeile code, wo der fehler geflogen ist.

und jetzt schau doch mal kurz auf http://c-plusplus.net/forum/viewtopic-var-p-is-841653.html
der trick mit den zweierpotenzen ist sicherlich nicht für eine generelle array-klasse zu gebrauchen. aber manchmal isser einfach gut. willst du in deiner sprache wirklich 20 sorten von arrays anbieten? kaum. in c++ kann man sich 20 sorten selber schreiben oder aus dem netz laden. man kann die klasse nehmen, die wirklich gut aufs problem paßt. ist das ein fehler?
und damit es dem user erlaubt ist, so sachen zu bauen, mußten halt ein paar sprachmittel wie operatorenüberladung, referenzen, konstruktoren und destruktoren her. naja, und nu, wo es erlaubt ist, und man sich array-klassen bauen kann, wozu sollte man die dinger auch noch in die sprache einbauen? als standard-lib dazugelegt reicht doch vollkommen.

[quote="volkardus"]
und jetzt schau doch mal kurz auf http://c-plusplus.net/forum/viewtopic-var-p-is-841653.html
der trick mit den zweierpotenzen ist sicherlich nicht für eine generelle array-klasse zu gebrauchen. aber manchmal isser einfach gut.

Ja, der Trick ist gut. Du bist sicherlich ein sehr guter C++ -Programmierer,
aber darum geht es mir eigentlich gar nicht. Es gibt in jeder Sprache sehr
gute Programmierer, was aber nicht heißt, daß jede Programmiersprache
die beste ist.

Ich programmiere nicht zum Selbstzweck und will auch keine "tricky"
Implementationen austüfteln, ich programmiere als Teil meines Jobs mit dem
Ziel, andere Routine-Arbeiten dadurch zu rationalisieren, und wenn ich zu diesem Ziel mit Python an einem halben Vormittag die Arbeit schaffe, wofür ich mit C++
anderthalb Wochen ansetzen mußte, dann ist die Wahl für mich klar.

[quote="Volkardus"]
willst du in deiner sprache wirklich 20 sorten von arrays anbieten? kaum. in c++ kann man sich 20 sorten selber schreiben

(ohne Worte)

Nein, mal im Ernst:
Heißt das, ich muß die Klasse einmal für 2^n schreiben, dann für 2^n+1,
2^n+2, 2^n+3, und vielleicht gibt's ja für 7|n noch eine "lecker" Beschleunigung
mit ein paar fiesen rekursiven Tricks, also die Klasse noch für 7|n und 8|n^2+1 separat implementieren. Ja, lüg' ich denn ?!

Ich dachte, eine höhere Programmiersprache dient dazu, Zeit zu *sparen*.

wozu sollte man die dinger auch noch in die sprache einbauen?

Damit Du schreiben kannst: L=["python ",2.4," is way cool"] ohne dazu einen Quelltext einhacken zu müssen, bei dem man nicht sicher ist, ob man erst den
EBCDIC-ASCII-Converter drüber laufen lassen sollte oder ob das schon der Klartext ist.

Grüße

Das Quoten muß ich nochmal üben...:

volkardus schrieb:

und jetzt schau doch mal kurz auf http://c-plusplus.net/forum/viewtopic-var-p-is-841653.html
der trick mit den zweierpotenzen ist sicherlich nicht für eine generelle array-klasse zu gebrauchen. aber manchmal isser einfach gut.

Ja, der Trick ist gut. Du bist sicherlich ein sehr guter C++ -Programmierer,
aber darum geht es mir eigentlich gar nicht. Es gibt in jeder Sprache sehr
gute Programmierer, was aber nicht heißt, daß jede Programmiersprache
die beste ist.

Ich programmiere nicht zum Selbstzweck und will auch keine "tricky"
Implementationen austüfteln, ich programmiere als Teil meines Jobs mit dem
Ziel, andere Routine-Arbeiten dadurch zu rationalisieren, und wenn ich zu diesem Ziel mit Python an einem halben Vormittag die Arbeit schaffe, wofür ich mit C++
anderthalb Wochen ansetzen mußte, dann ist die Wahl für mich klar.

Volkardus schrieb:

willst du in deiner sprache wirklich 20 sorten von arrays anbieten? kaum. in c++ kann man sich 20 sorten selber schreiben

(ohne Worte)

Nein, mal im Ernst:
Heißt das, ich muß die Klasse einmal für 2^n schreiben, dann für 2^n+1,
2^n+2, 2^n+3, und vielleicht gibt's ja für 7|n noch eine "lecker" Beschleunigung
mit ein paar fiesen rekursiven Tricks, also die Klasse noch für 7|n und 8|n^2+1 separat implementieren. Ja, lüg' ich denn ?!

Ich dachte, eine höhere Programmiersprache dient dazu, Zeit zu *sparen*.

wozu sollte man die dinger auch noch in die sprache einbauen?

Damit Du schreiben kannst: L=["python ",2.4," is way cool"] ohne dazu einen Quelltext einhacken zu müssen, bei dem man nicht sicher ist, ob man erst den
EBCDIC-ASCII-Converter drüber laufen lassen sollte oder ob das schon der Klartext ist.

Grüße

O'Rakl schrieb:

Nein, mal im Ernst:
Heißt das, ich muß die Klasse einmal für 2^n schreiben, dann für 2^n+1,
2^n+2, 2^n+3, und vielleicht gibt's ja für 7|n noch eine "lecker" Beschleunigung
mit ein paar fiesen rekursiven Tricks, also die Klasse noch für 7|n und 8|n^2+1 separat implementieren. Ja, lüg' ich denn ?!

leute wie du nehmen einfach std::vector und gut ist's. die klasse ist allgemein und normal schnell.
aber man *kann* es besser machen, wenn man will. in sprachen wie basic v2 sind arrays fest eingebaut und man kann sich keine eigenen mit ählich praktischer schnittstelle bauen. was ist nu besser? wenn man sich das bauen kann oder wenn man sich das nicht bauen kann? du mußt ja gar nicht alle features benutzen. ich hab nicht gesagt, daß DU es mußt. aber manche wollen es und deshalb geht es und dich stört's doch gar nicht. dir kann doch egal sein, ob vector jetzt in ner lib steht oder sprachmittel ist. mir isses nicht egal.

ChockoCookie

O'Rakl schrieb:

Ja, der Trick ist gut. Du bist sicherlich ein sehr guter C++ -Programmierer,
aber darum geht es mir eigentlich gar nicht. Es gibt in jeder Sprache sehr
gute Programmierer, was aber nicht heißt, daß jede Programmiersprache
die beste ist.

Ich hab hier niemanden behaupten sehn, dass C++ die _beste_ Sprache ist.
Ich mag Python auch sehr, aber es ist sicher auch nicht die beste Sprache. Insbesondere erzeugt ein guter C++ Programmierer sicher bessere Programme als ein guter Python Programmierer.
Dafür wird man ein leichter ein guter Python Programmierer als ein guter C++ Programmierer.
Ich stimme dir zu, das man bei Python kürzere Entwicklungszeiten hat als bei C++. Und das man dumm wäre Python nicht zu benutzen, wenn es die bessere Wahl ist. Aber OB Python die bessere Wahl ist, hängt nicht zuletzt davon ab, wie gut man programmieren kann.

O'Rakl schrieb:

Ich programmiere nicht zum Selbstzweck und will auch keine "tricky"
Implementationen austüfteln, ich programmiere als Teil meines Jobs mit dem
Ziel, andere Routine-Arbeiten dadurch zu rationalisieren, und wenn ich zu diesem Ziel mit Python an einem halben Vormittag die Arbeit schaffe, wofür ich mit C++
anderthalb Wochen ansetzen mußte, dann ist die Wahl für mich klar.

Wie vorher schon gesagt: Schön für dich

O'Rakl schrieb:

Volkardus schrieb:

willst du in deiner sprache wirklich 20 sorten von arrays anbieten? kaum. in c++ kann man sich 20 sorten selber schreiben

(ohne Worte)

Nein, mal im Ernst:
Heißt das, ich muß die Klasse einmal für 2^n schreiben, dann für 2^n+1,
2^n+2, 2^n+3, und vielleicht gibt's ja für 7|n noch eine "lecker" Beschleunigung
mit ein paar fiesen rekursiven Tricks, also die Klasse noch für 7|n und 8|n^2+1 separat implementieren. Ja, lüg' ich denn ?!

Du verwechselst _schon wieder_ können mit müssen.
Du kannst mit der Standard Implementation perfekt glücklich werden. Aber wenn du den zusätzlichen Speed brauchst kannst du drauf los schreiben. Bei Python geht das nicht. Es sei denn du willst ein gepatchtes Interpreter Binary mitliefern.

Und wer will das schon.

DEvent

Heißt das, ich muß die Klasse einmal für 2^n schreiben, dann für 2^n+1,
2^n+2, 2^n+3, und vielleicht gibt's ja für 7|n noch eine "lecker" Beschleunigung
mit ein paar fiesen rekursiven Tricks, also die Klasse noch für 7|n und 8|n^2+1 separat implementieren. Ja, lüg' ich denn ?!

ich würde mir eine Basisklasse für 2^n bauen und dann davon Klassen ableiten lassen für 2^n+1 und dann von dieser Klasse wiedreum eine weitere Klasse ableiten. Naja eh ein komisches Beispiel :p.
Das es in Python solche Datentypen gibt, gibts doch nur einen Grund: Um es Anfängern zu erleichtern mit der Sprache zu programmieren.

Was bei mir persönlich Kopfweh auslöst sind solche Sachen:
def foo(value): 
if (value==1): 
return 123; 
else: 
return list = ["1", "2", "3"] 

x = foo(1)

wieso hast du dicht noch immer nicht zu dem Code-Beispiel geäusert? Was macht der Compiler nun aus x ?
Was ist wenn ich sowas noch hinschreibe:

x = 10 * foo(10)

was passiert jetzt? Konvertiert der Compiler die Liste in einen Int-Typ ?
Bei diesem Codebeispiel fühle ich mich bestätigt, das Python eine Sprache für Anfänger ist, für die Leute die nocht nicht wissen was Typen sind und welche Vorteile es hat statische Typen zu haben.

Du sagt immer, das es ganz toll in Python ist, das man einen eingebauten GC hat, eingebaute Typen, keine delete, new, uvm, und wirfst C++ das genau Gegenteil vor. Aber: Du brauchst kein delete, new und keine eingebaute Typen.
delete, new : mach alles auf den Stack, funktioniert genau so gut.
einebaute Typen wie Tupel, Map usw: benutze eine Lib wie Boost oder was auch immer.

Du hast immer noch keinen Grund dafür genannt wieso eingebaute Typen ja so viel toller sind als Typen die man aus einer Lib bekommt. Der einzige Grund der mir einfällt ist nur Bequemlichkeit.

Ich kann dir aber ein Paar gute Gründe sagen die dafür sprechen keine eingebauten Typen zu haben.
Der wichtigeste Grund ist wohl der: wenn String in die Sprache eingebaut ist, dann gibt es nur diese eine Implementation von String. Der eingebaute Typ kann für mittlere Strings richtig gut funktionieren aber was ist mit richtig großen Strings oder ganz kleinen? Ich suche einfach eine Lib die einen String anbieren für große Strings. Mit eingebauten Typen kann ich das nicht.
Weiteres Beispiel: diese Liste in Python. Ist es eine doppelt-Verkettet ? Einfache ? Was ist wenn ich die Liste rückwärts durchsuchen will?

Fazit: Eingebaute Typen sind immer ein Mittelweg, mittig gut für alle Anwenungsmöglichkeiten, aber nirgendwo richtig gut. Wenn du richtige gute Implementierungen für eine spezielle Gegebenheit willst, kommst du nicht drumherum es selbst zu machen oder eine Lib zu benutzen. Also wieso nicht gleich eine Lib benutzen?

maximAL

Ben04 schrieb:

Wenn du mir zeigen kannst wo ich bei std::vector, boost::ptr_vector, boost::shared_ptr, boost::scoped_ptr oder bei std::string selbst um Kopiekonstruktor oder new/delete kümmern muß dann wechsele ich zu Python.

gleich 2 verschiedene managed pointer sowie ein pointer-container, alles aus einer 3rd party lib - was wolltest du noch gleich beweisen?

ChockoCookie

DEvent schrieb:

ich würde mir eine Basisklasse für 2^n bauen und dann davon Klassen ableiten lassen für 2^n+1 und dann von dieser Klasse wiedreum eine weitere Klasse ableiten. Naja eh ein komisches Beispiel :p.

Ich würde eher Traits nehmen.

DEvent schrieb:

Das es in Python solche Datentypen gibt, gibts doch nur einen Grund: Um es Anfängern zu erleichtern mit der Sprache zu programmieren.
Was bei mir persönlich Kopfweh auslöst sind solche Sachen:
def foo(value): 
if (value==1): 
return 123; 
else: 
return list = ["1", "2", "3"] 

x = foo(1)
wieso hast du dicht noch immer nicht zu dem Code-Beispiel geäusert? Was macht der Compiler nun aus x ?

Der "Compiler" macht gar nix draus. Der Interpreter bindet entweder ein Integer-Objekt oder ein Listen-Objekt an das Symbol x.

DEvent schrieb:

Was ist wenn ich sowas noch hinschreibe:
x = 10 * foo(10)
was passiert jetzt? Konvertiert der Compiler die Liste in einen Int-Typ ?

Nein, Python ist dynamisch Typisiert, aber nicht schwach Typisiert. dh falls eine Funktion (in diesem Fall der * Operator) nicht definiert ist, gibts eine Runtime Exception.
[edit] In diesem Fall ist der * Operator so definiert, dass er die Liste vervielfältigt und aneinandergehängt zurückgiebt (als neue Liste)[/edit]

DEvent schrieb:

Bei diesem Codebeispiel fühle ich mich bestätigt, das Python eine Sprache für Anfänger ist, für die Leute die nocht nicht wissen was Typen sind und welche Vorteile es hat statische Typen zu haben.

Und bei dieser Aussage fühle ich mich bestätigt, das du die Vorteile der dynamischen Typisierung in Python nicht verstanden hast.
Du musst bei Python sehr wohl wissen was Typen sind. Und wie man die Vorteile dynamischer Typen gewinnbringend einsetzt.

Ben04

ChockoCookie schrieb:

ich würde mir eine Basisklasse für 2^n bauen und dann davon Klassen ableiten lassen für 2^n+1 und dann von dieser Klasse wiedreum eine weitere Klasse ableiten. Naja eh ein komisches Beispiel :p.

Ich würde eher Traits nehmen.

Ich würde eher zu einer Policy basierten Lösung hin tendiren.

ChockoCookie schrieb:

Und bei dieser Aussage fühle ich mich bestätigt, das du die Vorteile der dynamischen Typisierung in Python nicht verstanden hast. Du musst bei Python sehr wohl wissen was Typen sind. Und wie man die Vorteile dynamischer Typen gewinnbringend einsetzt.

Also kann man sich auch bei Python in den Fuß schießen und zwar ganz gewaltig! Ich kenne keine Situation wo das von dir beschriebene Verhalten angebracht wäre. Mit C oder C++ wäre dir das nicht passiert.

maximAL schrieb:

gleich 2 verschiedene managed pointer sowie ein pointer-container, alles aus einer 3rd party lib - was wolltest du noch gleich beweisen?

Gut man kann daraus natürlich auch nur boost::shared_ptr und std::vector<boost::shared_ptr<> > machen. Wäre auch besser angebracht als Vergleich da man in Pyhton ja auch nur ein Konstrukt hat das für alle Situation herhalten muß.

Ben04 schrieb:

Also kann man sich auch bei Python in den Fuß schießen und zwar ganz gewaltig!

So, wie denn ? Ich habe noch nie ein Python-Programm abstürzen sehen.
Schlimmstenfalls stoppt die PVM mit Fehlermeldung/Exception und Zeilenangabe.

Ich kenne keine Situation wo das von dir beschriebene Verhalten angebracht wäre. Mit C oder C++ wäre dir das nicht passiert.

Bei generischen Algorithmen ist die Ein- und Ausgabe von Datentypen,
die erst zur Laufzeit fest liegen, nicht nur Gang und Gäbe, sondern
sogar Prinzip. In Python ist das nur so einfach, dass es jeder nutzen kann,
wogegen in C++ zur Nutzung von RTTI und STL ein Vorwissen im Umfang eines halben Informatik-Grundstudiums praktisch vorausgesetzt wird.

Wäre auch besser angebracht als Vergleich da man in Pyhton ja auch nur ein Konstrukt hat das für alle Situation herhalten muß.

[/quote]

Die Verbindung von Einfachheit und Allgemeinheit ist eben wahre Eleganz. Das ist in der Mathematik nicht anders als bei Programmiersprachen.