vergesst C++ ...

Talla

volkard schrieb:

.aw schrieb:

Komischerweise gibt es kein Wort das per Definition das genaue Gegenteil von Müll ist.

komisch?
haben nicht fast alle wörter kein gegenteil?
ich teste mal.
auto
baum
apfelkuchen
computer
taschentuch
alkohol
tintenstrahldrucker
feuerzeug

hmm. keins der wörter hat ein gegenteil, oder?

Substantive haben in den seltensten Fällen Gegenteile - bei Adjektiven siehts schon ganz anders aus.

Volkard schrieb:

python ist müll für dumme masochisten.

bist ein echter Kenner, hmm ?

volkard

O'Rakl schrieb:

Volkard schrieb:

python ist müll für dumme masochisten.

bist ein echter Kenner, hmm ?

eigentlich mag ich python sehr. aber in diesem thread war es irgendwie notwenig, völlig unbegründet python schlechtzumachen. und ich hab keine pseudoargumente davorgeschoben, sondern einfach getrollt. da weiß man, was man hat.
ein paar argumente sagte ich ja nur dazu, daß c++ nicht so schlimm ist, wie du es glauben machen willst.

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.