ZFX + Developia

jo, hab mich dann dafür entschieden eine DMAX Prepaid karte zu holen...
naja, vielleicht mach ich ja nen neuen account mit meiner neuen adresse und neuem Konto, weil das ja schwachsinn ist, dass amazon mir das Bezahlen per Lastschrift nicht erlaubt.. ich habe keinerlei schulden und mein Konto ist immer gedeckt, wenn ich bestelle...

http://www.heise.de/ct-tv/artikel/Hinte ... 38348.html
http://www.fr-online.de/politik/spezial ... index.html

Das geht ja noch :). Wir hatten ein Problem mit T-Online, die zur Rückzahlung falsch abgebuchter Gebühren erst nach 1/2 Jahr, zirka 7-8 telefonaten, mehreren Briefen und ungezählten Tassen Baldrian-Tees bereit waren. Noch heute träume ich von der Warteschleifen-Musik!

Gruß Kimmi

*Aushol*

• Apopo (wollte nur mal „Popo“ sagen) T-Online – deren Kunden kommen seit vorgestern abend nicht mehr in ICQ.
• Wie abgrundtief lächerlich und für den Popo (nochmal) ist eigentlich diese ganze elendige LF- / CR+LF- / CR-Sache?!? Wirklich, dass man sich im Jahr 2010 noch nicht darauf geeinigt hat ist doch eine pure Farce. Ich speichere jetzt alles nurnoch mit LF; wer es nicht lesen kann, soll sich Notepad++ saugen … seien wir doch ehrlich: wenn wir jetzt nicht anfangen, diesen Irrsinn zu stoppen, dann setzt sich CR+LF bis zum Jahr 2050 vollends durch. FUCK THE SYSTSEM
• Ich hasse die STL! Die haben ihre Streams doch genauso in den Sand gesetzt wie wchar_t. Nochmal zur Erinnerung: ::std::cout << "igitt!" << ::std::endl; bedeutet, dass jeder Buchstabe des Strings geparst wird. Falls er aus der ASCII-Tabelle rausfällt, wird das aktuelle Locale geladen, der Buchstabe darin nachgeschlagen, übersetzt, eingefügt. Dieses Einfügen geht dann durch fünf virtuelle Funktionsaufrufe, die fast alle nochmal Buchstabe für Buchstabe arbeiten und im Fall einer Dateiumleitung – siehe Punkt darüber – den Zeilenumbruch durch CR+LF ersetzen. Dann wird gepuffert und (in keinem erkennbaren Muster) in stdio-FILE*s geflusht, die wiederum nur Umleitungen für Windows-Files sind.
  Da ich nur mit UTF-8 arbeite, brauche ich 99 % der Implementierung nicht (höchstens eine Assertion, dass das, was ich schreibe, auch gültige UTF-8-Code-Points-sind) – und erst recht brauche ich keine Funktion, die compile-time-constant Strings Byte für Byte durchgeht! Das klatsche ich jetzt alles in einem Rutsch in eine Windows-File, verliere 30 % Abhängigkeiten, gewinne 10 % Kompilierzeit und zigfache I/O-Performance und packe den Scheiß nie mehr mit der Kneifzange an. Lächerlich.
• Warum setzt eigentlich die ganze Welt auf nullterminierte Strings?!? Es gibt in der IT sicher wenig Objekte, die sich noch langsamer und umständlicher verarbeiten lassen … Pascal-Strings forever!
• Gibt es eigentlich keine einzige int-to-String-Implementierung, die halbwegs schnell ist?!? Oder für Zehnerbasis optimiert ist? Ich sehe jetzt schon, dass ich die nächsten Wochen damit verbringe, alle itoa()- und fcvt()-Variationen von Hand gemäß einem Code-Stück optimiere, das ich mal von Aramis gekriegt habe. Es gibt einfach keine Qualität mehr.
• Wth musste Robbie heiraten?!?

*schnauf*

@Krishty: Du nimmst das einfach viel zu persönlich :)!

Gruß Kimmi

Wenn diese Idiotie nicht gegen mich, sondern gegen die gesamte Programmiererschaft gerichtet ist, ist das für mich erst recht ein Grund, mich aufzuregen ;)

Achja – ich habe gerade irgendwo einen operator << () überladen und nun schlagen alle meine überladenen operator << ()s an allen anderen Stellen, die von dem neuen Operator komplett abgekapselt sind, vollends fehl. Wtf

[...]Wth musste Robbie heiraten?!?

One of these things is not like the others.

Wieso hat ausgerechnet Qt als "objekt-orientiertes" Framework diese unglaubliche Ausrichtung auf zentralistische Hash-Map-Verwaltung, das ist weder elegant, noch einfach und erfordert einen permanenten Verwaltungsaufwand um ebendiese Maps aktuell zu halten. UND warum zwingt mich Qt, sobald es um Objekthierarchien oder sonst irgendwelche Objektbeziehungen geht, meinen Code wie schon zu C-Zeiten in wenige geballte Event-Funktionen zu packen, wobei gleichzeitig der richtige Ort für diesen Code nur zum Schauplatz nichtssagender einzeiliger Delegationsaufrufe ans Event-System wird?!?

Ich tipp mal nur die, zu denen ich was sagen kann.

Krishty hat geschrieben: [*]Ich hasse die STL! Die haben ihre Streams doch genauso in den Sand gesetzt wie wchar_t. Nochmal zur Erinnerung: ::std::cout << "igitt!" << ::std::endl; bedeutet, dass jeder Buchstabe des Strings geparst wird. Falls er aus der ASCII-Tabelle rausfällt, wird das aktuelle Locale geladen, der Buchstabe darin nachgeschlagen, übersetzt, eingefügt. Dieses Einfügen geht dann durch fünf virtuelle Funktionsaufrufe, die fast alle nochmal Buchstabe für Buchstabe arbeiten und im Fall einer Dateiumleitung – siehe Punkt darüber – den Zeilenumbruch durch CR+LF ersetzen. Dann wird gepuffert und (in keinem erkennbaren Muster) in stdio-FILE*s geflusht, die wiederum nur Umleitungen für Windows-Files sind.
Da ich nur mit UTF-8 arbeite, brauche ich 99 % der Implementierung nicht (höchstens eine Assertion, dass das, was ich schreibe, auch gültige UTF-8-Code-Points-sind) – und erst recht brauche ich keine Funktion, die compile-time-constant Strings Byte für Byte durchgeht! Das klatsche ich jetzt alles in einem Rutsch in eine Windows-File, verliere 30 % Abhängigkeiten, gewinne 10 % Kompilierzeit und zigfache I/O-Performance und packe den Scheiß nie mehr mit der Kneifzange an. Lächerlich.

Ich hab mal irgendwo gelesen, dass die Streams sehr viel schneller sind, wenn sie nicht mehr syncron zu den alten FILE* sein müssen. Ich kann Dir leider keine Details nennen, aber es gibt da einen Flag, den man ganz am Anfang setzen kann, so dass die Synchronität geknickt wird.

Nebenbei: was benutzt Du für UTF8-Strings? Gibt's da irgendwo brauchbare Stringklassen für, die gleich die gängigen Stringoperationen mit anbieten?

[*]Warum setzt eigentlich die ganze Welt auf nullterminierte Strings?!? Es gibt in der IT sicher wenig Objekte, die sich noch langsamer und umständlicher verarbeiten lassen … Pascal-Strings forever!

Alle Welt nutzt eigentlich std::string, was intern ebenso ein "Pascal-String" ist, plus ein paar Optimierungen.

[*]Gibt es eigentlich keine einzige int-to-String-Implementierung, die halbwegs schnell ist?!? Oder für Zehnerbasis optimiert ist? Ich sehe jetzt schon, dass ich die nächsten Wochen damit verbringe, alle itoa()- und fcvt()-Variationen von Hand gemäß einem Code-Stück optimiere, das ich mal von Aramis gekriegt habe. Es gibt einfach keine Qualität mehr.

Wir haben für Assimp damals mal ein atoi() selbst geschrieben, weil das eingebaute atoi() aus der VisualC-Standardlib immer zuerst ein strlen() auf den übergebenen String ausgeführt hat... net übel, wenn man damit MultiMB-XFiles liest. Ich benutze in privatem Code jetzt immer gern boost::lexical_cast, aber über dessen Performance kann ich Dir nix sagen.

Auch dazu kann ich was sagen, denke ich :-)

CodingCat hat geschrieben:Wieso hat ausgerechnet Qt als "objekt-orientiertes" Framework diese unglaubliche Ausrichtung auf zentralistische Hash-Map-Verwaltung, das ist weder elegant, noch einfach und erfordert einen permanenten Verwaltungsaufwand um ebendiese Maps aktuell zu halten.

Du meinst die globale qHash()-Funktion, die für die QHash<>-Klasse notwendig ist? Die ist wirklich hässlich... ein generischer Funktor als Template-Argument wär cooler gewesen...

UND warum zwingt mich Qt, sobald es um Objekthierarchien oder sonst irgendwelche Objektbeziehungen geht, meinen Code wie schon zu C-Zeiten in wenige geballte Event-Funktionen zu packen, wobei gleichzeitig der richtige Ort für diesen Code nur zum Schauplatz nichtssagender einzeiliger Delegationsaufrufe ans Event-System wird?!?

Den verstehe ich nicht. Es gibt für jeden Event-Typen eine spezialisierte Memberfunktion - timerEvent(), keyPressEvent() usw. Und für alle QUI-Aktionen sind eh die Signal/Slot-Dinger gedacht. Was genau stört Dich daran?

Schrompf hat geschrieben:Ich hab mal irgendwo gelesen, dass die Streams sehr viel schneller sind, wenn sie nicht mehr syncron zu den alten FILE* sein müssen. Ich kann Dir leider keine Details nennen, aber es gibt da einen Flag, den man ganz am Anfang setzen kann, so dass die Synchronität geknickt wird.

Klingt schon besser – aber weniger Overhead ist immernoch zuviel. Allein, was an statischen Daten in meinem Programm landet, weil die STL dauernd irgendwelche Locales braucht, jagt mir kalte Schauer über den Rücken :(

Schrompf hat geschrieben:Nebenbei: was benutzt Du für UTF8-Strings? Gibt's da irgendwo brauchbare Stringklassen für, die gleich die gängigen Stringoperationen mit anbieten?

Selbstgeschrieben; nach Biolunars Empfehlung mit UTF8-CPP.

Schrompf hat geschrieben:Alle Welt nutzt eigentlich std::string, was intern ebenso ein "Pascal-String" ist, plus ein paar Optimierungen.

Schön wär’s – schließlich ist jedes String-Literal in C++ nullterminiert. Das Schlimme ist, dass Visual C++ strlen() scheinbar überall auflöst, nur nicht in den operator << ()s und in String-K’toren (offenbar meint der Optimizer, dass ein Inlining an so vielen Stellen die Exe zu sehr aufblähen würde, unwissend, dass das alles zu einer einzigen Zahl kollabiert). Die WinAPI erwartet auch überall eine Null hinter. Man arbeitet also zwar nicht durchweg mit nullterminierten Strings, aber verschiebt das Problem von der Nutzung zur Initialisierung.

Schrompf hat geschrieben:Wir haben für Assimp damals mal ein atoi() selbst geschrieben, weil das eingebaute atoi() aus der VisualC-Standardlib immer zuerst ein strlen() auf den übergebenen String ausgeführt hat... net übel, wenn man damit MultiMB-XFiles liest. Ich benutze in privatem Code jetzt immer gern boost::lexical_cast, aber über dessen Performance kann ich Dir nix sagen.

Ja, genau das habe ich bekommen.

Achja – ich habe gerade irgendwo einen operator << () überladen und nun schlagen alle meine überladenen operator << ()s an allen anderen Stellen, die von dem neuen Operator komplett abgekapselt sind, vollends fehl. Wtf

Der ADL-Teufel? :-)

Heißt das nicht „Koenig Lookup“? Edit: Wikipedia sagt, wir haben beide recht.

Jedenfalls habe ich gerade herausgefunden, dass die Operatoren im selben Namespace überladen werden müssen, in dem auch der Typ des Parameters steckt, für die man überlädt … sonst explodiert das gesamte Programm in einer Wolke aus Fehlermeldungen und fetzenden Namespace-Schrapnellen.

Schrompf hat geschrieben:Du meinst die globale qHash()-Funktion, die für die QHash<>-Klasse notwendig ist? Die ist wirklich hässlich... ein generischer Funktor als Template-Argument wär cooler gewesen...

Nein, ich zielte eher darauf ab, dass ich in einem AbstractItemModel mit dem einen internal void* Pointer pro Model-Index keinerlei Möglichkeiten sehe, elegant und Typ-sicher eine schöne Objekt-Hierarchie auf das AbstractItemModel-Interface und somit auf entsprechende Views abzubilden.

Schrompf hat geschrieben:Den verstehe ich nicht. Es gibt für jeden Event-Typen eine spezialisierte Memberfunktion - timerEvent(), keyPressEvent() usw. Und für alle QUI-Aktionen sind eh die Signal/Slot-Dinger gedacht. Was genau stört Dich daran?

Genau da liegt das Problem, eine Methode pro Event-TYP und nicht pro Event. Aber richtig, das wäre noch erträglich... wenn da nicht Event Filters wären, bei denen einfach alles in einer event-Methode landet. Signal/Slot nutze ich wo es nur geht, aber das ist ein weiterer wichtiger Punkt: Qt bietet einfach für viel zu wenige Ereignisse Signale an. Nicht Mal elementarste Dinge wie das Verschieben, Resizen, ja gar das Schließen von Fenstern werden abgedeckt?!?

Ganz ehrlich verstehe ich nicht, warum überhaupt Events, wesentlich konsequenter wäre, einfach alles mit Signal/Slot zu realisieren. Da geht es nämlich gerade weiter, die Tatsache, dass dieser ganze Mist an Events über Vererbung läuft, ist nochmal ein riesen Unsicherheits- und dank Doku auch noch Ungewissheitsfaktor.

Live aus dem QtSolutions Property Browser Extension Source: Frage: Wie und wie oft wird hier in Maps gesucht? Ach, Suchen geht ja in logarithmischer Zeit... Ich sollte anmerken, dass in dieser Map fast nie viel drin ist, aber bei so Code wird mir aus Prinzip übel. Diesen Schnipsel findet man im Übrigen genau so auch als Beispielimplementierung.

Meine Festplatte stirbt :-( 500GB Western Digital, gradmal ein Jahr alt. Die Samsung davor ist auch ein Jahr alt geworden. Gibt es denn keine Hersteller mehr, auf die man sich verlassen kann? Meine alten 80GB-Platten von anno dunnemals laufen heute noch... alle seitdem nicht mehr. Verdammter Mist. Um so einen Scheiß wollte ich mich eigentlich nicht mehr kümmern müssen.

Gott sei Dank ist alles Wichtige auf der SSD.

Ich habe von Western Digital 3 × 1 GiB – eine habe ich gebraten, als ich den Adapter meines Lenkrads mit dem der Platte vertauscht habe, aber die anderen beiden laufen trotz Dauerbelastung (ständige Defragmentierung, dauerndes Umschichten) einwandfrei. Von Samsung habe ich eine 200er, die seit nun über fünf Jahren problemlos funktioniert. Hat zwei Betriebssysteme, >8000 Systemstarts und bestimmt tausend Defragmentierungen überlebt, das zähe Biest …

… und dennoch halte ich alles redundant vor.

Ich habe von Western Digital 3 × 1 GiB

Willst du mir einen grossen Haufen Disketten abkaufen?

Poah, das ist sogar doppelt falsch. Diese hinterlistigen Leute verkaufen schließlich nur TB statt TiB.

Ich nehme mal an, den xkcd–Link koennen wir uns sparen :-)

Wir uns schon – aber wenn man es in der breiten Öffentlichkeit erwähnt, muss man auch delivern.

Mal was ganz ganz Tolles: und jetzt: Was ist der Unterschied?
Der Compiler kann den K’tor (in diesem Fall von einer Festkommaklasse) nicht wegoptimieren; auch COMDAT-Folding ist machtlos (warum auch immer). Der erste Code legt in jeder Object-File, in der er inkludiert wird, einen Initializer für J2000 an. Der Zweite nur einen einzigen. Edit: Das gilt auch für jede Art von struct, das man global const anlegt.

Das sieht dann im Dump so aus:vsHübsch, oder? 15 cpp-Dateien hatten den Header #included; und die zweite Methode spart gegenüber der ersten 470 B Maschinencode, 64 B read-only-Daten, 128 B read-write-Daten und 74 Relocations beim Laden der Exe.

Manchmal will ich garnicht glauben, wie stark der Optimizer an Syntaxdetails hängt … (der Dump stammt übrigens vom exzellenten Tool Sizer, das mir Psycho empfohlen hat.)

P.S.: GS_ContextRecord und GS_ExceptionRecord sind auch ein toller Grund zu jammern. Die sind in der Windows-Fehlerberichterstattung verankert und werden benutzt, falls Stack oder Exception-Handler überschrieben wurden (bspw, weil jemand seinen Code einschleusen will). Eigentlich eine sehr sinnvolle Sache, aber für meinen Geschmack ein bisschen viel Overhead für ein Feature, das sich (im Gegensatz zum Großteil der CRT) nicht durch eigenen Code ersetzen lässt.

P.P.S: ICQ geht wieder, juhu.

Das hier ist evtl. ein ganz schlichter Fehler: "static" bedeutet global/in Namespaces was anderes als in Klassen oder Funktionen :-) Im globalen bedeutet es nämlich "nur für diese Übersetzungseinheit". Wenn Du in einer CPP eine static-Var global anlegst, ist die nur in dieser CPP gültig und kommt nicht in Konflikt mit gleichnamigen Vars in anderen Übersetzungseinheiten. Wenn Du demzufolge eine static Var in einem Header anlegst, bekommt jede CPP-Datei ihre eigene Version der Variable.

Schrompf hat Recht, genau wie der Compiler. Der Sprachstandard schreibt vor dass static-Daten in jeder Uebersetzungseinheit, die sie nicht als extern referenziert, neu angelegt werden muessen (afaik koennte das uebrigens auch fuer static lokale Variablen in von mehreren Units inkludierten Funktionen gelten … aber da bin ich mir nicht ganz sicher).

Daraus folgt (afaik…) aber auch, dass sie in jeder Uebersetzungseinheit eine andere Adresse haben muessen, also kann der Linker sie eigentlich nicht zusammenoptimieren, selbst wenn er sieht dass alle den gleichen Wert haben.

Genau dafuer (weil static ausserhalb von Klassen damit so gut wie nutzlos und zudem auch noch gefaehrlich unintuitiv ist) gibt es selectany (http://msdn.microsoft.com/en-us/library ... S.80).aspx). Nicht dass es damit besser wuerde …

Schrompf hat geschrieben:Das hier ist evtl. ein ganz schlichter Fehler: "static" bedeutet global/in Namespaces was anderes als in Klassen oder Funktionen :-)

Das ist kein Fehler; habe ich auch nie behauptet (oder ist das Bug-Report-Prävention? :) ). Allerdings impliziert const in C++ automatisch static – mir geht nicht auf den Nerv, dass es überhaupt so gemacht wird, sondern, dass das der Default-Weg ist … wer kommt schon von allein darauf, unveränderliche Daten immer und überall extern zu deklarieren … :( constexpr ist sowas von überfällig …

Aramis hat geschrieben:Daraus folgt (afaik…) aber auch, dass sie in jeder Uebersetzungseinheit eine andere Adresse haben muessen, also kann der Linker sie eigentlich nicht zusammenoptimieren, selbst wenn er sieht dass alle den gleichen Wert haben.

Ist das nicht dieselbe Grauzone wie COMDAT-Folding generell?

Aramis hat geschrieben:Genau dafuer (weil static ausserhalb von Klassen damit so gut wie nutzlos und zudem auch noch gefaehrlich unintuitiv ist) gibt es selectany (http://msdn.microsoft.com/en-us/library ... S.80).aspx). Nicht dass es damit besser wuerde …

Vor allem funktioniert es nur mit nativen Typen … jedenfalls so weit ich die Fehlermeldungen heute nacht entziffern konnte.

Krishty hat geschrieben:

Schrompf hat geschrieben:Das hier ist evtl. ein ganz schlichter Fehler: "static" bedeutet global/in Namespaces was anderes als in Klassen oder Funktionen :-)

Das ist kein Fehler; habe ich auch nie behauptet (oder ist das Bug-Report-Prävention? :) ). Allerdings impliziert const in C++ automatisch static 

Öh... nein? Warum sollte const ein static implizieren? Das ist nach meinem Wissen weder in Klassen noch in Funktionen noch im globalen Scope so.

http://msdn.microsoft.com/en-us/library/5tkz6s71 hat geschrieben://Incorrect - const is by default static in C++, so
//x2 is not visible externally (This is OK in C, since
//const is not by default static in C)
const __declspec(selectany) int x2 =2;

Eine unabhängige Quelle wäre mir auch lieber, aber ich finde gerade keine. Klingt aber sinnvoll – sonst würde int const GlobalConstant = 0; in einem Header, der mehrfach #includet wird, ja unzählige Linkerfehler bewirken.

Hm. Ich dächte, der kann solche Konstanten dann einfach vereinen, wie er das bei Strings und identischen Funktionen ja auch tut. Bzw. const int und sowas würde ja eh bei hinreichend hoher Optimierung direkt in Register geladen werden, ohne dafür Speicher in der Exe zu reservieren.
[edit] Hast Du's einfach mal ausprobiert, die Deklaration ohne "static" zu schreiben? Sieht der generierte Code dann genauso aus?

Schrompf hat geschrieben:Bzw. const int und sowas würde ja eh bei hinreichend hoher Optimierung direkt in Register geladen werden, ohne dafür Speicher in der Exe zu reservieren.

Genau, bei nativen Datentypen tut er das auch. (Bei Strings muss man erst String-Pooling aktivieren, bei Funktionen COMDAT-Folding.) Aber irgendwie scheint der ganze Rest da rauszufallen … also bei Bedarf über den Code gucken, ob man irgendwo global ein struct oder eine class mit const deklariert hat und auslagern, um Platz zu sparen. Warum sie den einfachen/offensichtlichen Weg so ineffizient gemacht haben, bleibt mir ein Rätsel -.-

Edit: Nein, probiere ich direkt mal.

Edit 2: Ich kann es nicht genau sagen, weil ich natürlich noch gestern abend hunderte globale Konstanten auf extern umgestellt habe und es nun ein wenig viel Aufwand wäre, das rückgängig zu machen – aber const schneidet auf den ersten Blick mindestens genauso schlecht ab wie static const.

Ich hasse die C++-Standardbibliothek. Wie tief sie in der Sprache verwoben ist genauso wie, wie sie implementiert ist.
Ich will nicht ::std::exception benutzen müssen. Ich will außerdem Placement-new überschreiben können.