vergesst C++ ...

[volkard]

O'Rakl schrieb:

Angesichts der überbordenden Komplexität von STL und boost zum Nachbilden
teilweise einfachster Datenstrukturen drängt sich
dann aber doch die Frage auf, ob es nicht besser wäre, zumindest die allereinfachsten und in fast jedem Programm benötigten Datenstrukturen List,String und Map doch fest in eine Sprache einzubauen.

äh, warum das denn?
kann dir doch egals sein, wie die implementier sind, solange sie einfach zu bedienen sind.
und als nicht-sprachmittel können sie relativ ausgetauscht werden, wenn's besser implemetierungen irgendwo gibt.

[O'Rakl]

[quote="volkard"]
äh, warum das denn? kann dir doch egals sein, wie die implementier sind, solange sie einfach zu bedienen sind.
[quote]

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

C++ kann schon gemein sein für Nicht-Experten.

und als nicht-sprachmittel können sie relativ ausgetauscht werden, wenn's besser implemetierungen irgendwo gibt.

Das bezweifle ich in den meisten Fällen. Ein Bib etwa für Garbage Collection
kannst Du nicht so ohne Weiteres austauschen, sofern verschiedene Algorithmen
verwendet werden. Generell muß der Programmierer bei C++ irgendwie viel zu
viel Details wissen, die ihn bei der Lösung seines Problems eigentlich
gar nichts angehen. Unglücklicherweise sind es gerade *die* Dinge, die
dem Programmierer überlassen werden, die besonders fehlerträchtig sind,
wenn man nicht genau aufpaßt (s. Freigeben von Speicher, Löschen von Objekten,
Konstruktoren überladen usw...)

[volkard]

O'Rakl schrieb:

Unglücklicherweise sind es gerade *die* Dinge, die
dem Programmierer überlassen werden, die besonders fehlerträchtig sind,
wenn man nicht genau aufpaßt (s. Freigeben von Speicher, Löschen von Objekten,
Konstruktoren überladen usw...)

nu kommen wir aber zu des pudels kern. du machst dauernd fehler bei freigaben, löschungen und konstruktoren. und deswegen magste c++ nicht. ich mach da aber keine fehler und mag c++.
und ich werde nicht zu einer anfängersprache umsteigen, nur weil du lernschwach bist.

[Gast]

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

[Redhead]

volkard schrieb:

O'Rakl schrieb:

Unglücklicherweise sind es gerade *die* Dinge, die
dem Programmierer überlassen werden, die besonders fehlerträchtig sind,
wenn man nicht genau aufpaßt (s. Freigeben von Speicher, Löschen von Objekten,
Konstruktoren überladen usw...)

nu kommen wir aber zu des pudels kern. du machst dauernd fehler bei freigaben, löschungen und konstruktoren. und deswegen magste c++ nicht. ich mach da aber keine fehler und mag c++.
und ich werde nicht zu einer anfängersprache umsteigen, nur weil du lernschwach bist.

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

[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.

[Redhead]

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..."

[O'Rakl]

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?

[O'Rakl]

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?

[O'Rakl]

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.

[volkardus]

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.

[O'Rakl]

[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

[O'Rakl]

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

[volkardus]

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.