vergesst C++ ...

kartoffelsack

(Aber ich kapier auch die BOOST Library nicht, ist mir zu unlesbar,

sorry, das versteh ich aber nicht. Ok, dass Volkard die STL nicht mag, ist bekannt, soweit ich mich erinnere aber hauptsächlich wegen der Notation (alles klein schreiben und so). Das ist aber Geschmackssache. Aber mal abgesehen davon. Wenn man ein bisschen gewohnt ist mit templates umzugehen, ist Boost wirklich nicht unlesbar oder schwer. Da wo das ganze in der stl kompliziert wird mem_fun_ref etc. gibts in boost oft viel einfachere Lösungen, weil die oft auch auf lesbarkeit und benutzbarkeit geachtet haben. Ok, wenn man sich den boost-Code selber anguckt, der ist vielleicht nicht ganz ohne. Aber immerhin macht die Bib was, was bei anderen Compilern in die Sprache eingebaut ist. Und den Compiler guck ich mir ja auch nicht mal so zwischendurch an.

Problem sind natürlich immer die Fehlermeldungen, die einen irgendwo mitten in die Bib befördern.

Power Off

kartoffelsack schrieb:

Ok, wenn man sich den boost-Code selber anguckt, der ist vielleicht nicht ganz ohne. Aber immerhin macht die Bib was, was bei anderen Compilern in die Sprache eingebaut ist. Und den Compiler guck ich mir ja auch nicht mal so zwischendurch an.

Problem sind natürlich immer die Fehlermeldungen, die einen irgendwo mitten in die Bib befördern.

Ja, genau das meinte ich.

Wenn ich was verstehen will, guck ich in den Source. Die STL versteh ich, aber BOOST?

Hab mir's grade noch mal angeguckt -- na ja, so schlimm ist's jetzt auch wieder nicht, hatte wohl neulich eine Mattscheibe.

Ich wollte grade schreiben, daß C++ am Rande der C++ Implementation agiert und deswegen kaum portabel ist, aber das ist wohl gar nicht der Fall.

Muß mir die Library noch mal genau angucken!

Vielleicht kann ich so noch mehr Zeit sparen!

[quote=Kartoffelsack]
Aber immerhin macht die Bib was, was bei anderen Compilern in die Sprache eingebaut ist.
[/quote]

na, immerhin

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.

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.

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

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

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.

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