ZFX + Developia

Ich hasse es, wenn ein technisches Problem so speziell wird, dass alle meine Web-Suchen danach immer meine eigenen Fragen dazu unter den ersten Treffern listen :(

Wenn ihr auch die neuen C++-Features von Visual Studio 2012 CTP benutzen wollt, aber nicht könnt, weil ihr noch auf Nvidia Nsight wartet: Ihr müsst nur noch von April bis Juni 2013 darauf warten.

Wenigstens gibt es dann Single-GPU-Debugging; übrigens auch für GLSL. Aber das gehört eigentlich in den anderen Thread.

Immer wenn mich mal wieder der Ehrgeiz packt, in einem bestimmten isolierten Projekt (d.h. keine lean-Bibliothek) noch C++03-kompatibel zu bleiben, stelle ich mit Schrecken fest, wie unmöglich es vor C++11 ohne Move Semantics de facto war, sinnvollen C++-Code zu schreiben. Da bleiben schlussendlich nur Boost Pointer Container Wrappers oder TR1 Shared Pointers als suboptimaler Ausweg.

Damit ist dieser Post nur teilweise ein Jammer-Post, weil er auch feststellt, dass C++11 tatsächlich ein außerordentlich wichtiger und weitestgehend geglückter Schritt ist. Er ist ein Jammer-Post, weil es dazu keine Move Semantics gebraucht hätte, sondern bereits C++98 mit geeigneten STL-Container-Interfaces, die wahlweise echte Reallokation oder Move-by-Swap bieten (solche habe ich z.B. in lean), eine vernünftige Programmiersprache hätte sein können, die uns mehr als 10 Jahre Müll hätte ersparen können.

Google Chrome benutzt GetCursorPos() statt GetMessagePos(). Bei meinem Netbook ist die Latenz systembedingt hoch, und jetzt schmeiße ich deshalb dauernd meine Tabs durcheinander.

Für alle, die an einer GUI werkeln, und nicht wissen, wovon ich hier rede: Ihr seid tickende Zeitbomben; lest http://blogs.msdn.com/b/oldnewthing/arc ... 71135.aspx . (Nicht böse gemeint – der Fehler ist irre weit verbreitet; seht ihr ja an Chrome.)

An einer GUI zu werkeln und den Input nicht über Windows Messages zu machen, ist doch sowieso Wahnsinn!?

Sie machen den Input wohl über Windowsnachrichten, nur – wenn die WM_LBUTTONUP eintrudelt, bestimmen sie die Zeigerposition via GetCursorPos(). Wegen der Systemlatenz ist mein Zeiger ganz woanders und jeder Klick wird zu Drag & Drop.

Aber falls du meintest, dass man die Drag & Drop-Erkennung über Windows-Nachrichten machen sollte, hast du natürlich auch recht. Ich kenne mich nur selber nicht genug aus um zu wissen, ob es dafür Nachrichten gibt und wie das mit deren erweiterter Client-Area harmoniert.

unsigned short foo = …;
foo += 0xFFFF;

Der smaller Type Check von VC++ löst da aus. Weil das Zwischenergebnis zu int promotet wird und der Dreckscompiler nicht erkennt, dass das += ist und der Typ unsigned und das darum alles wohldefiniert ist.

EINE MILLION ASSERTIONS WEGKLICKEN KLAAAAR

Sicher, dass das wohldefiniert ist? Signed Integer Overflow ist afaik nämlich UB...

Ja. signed ist undefiniert (weil es Two's Complent; One's Complement oder sonstwas sein könnte); unsigned ist als Modulo definiert.

Wie du selbst sagst, ist dein Zwischenergebnis aber signed... ;)

Aber ganz egal, was in foo drinsteht – das int läuft niemals über; nur das unsigned short, dem es zugewiesen wird, ist zu klein.

Krishty hat geschrieben:Google Chrome benutzt GetCursorPos() statt GetMessagePos(). Bei meinem Netbook ist die Latenz systembedingt hoch, und jetzt schmeiße ich deshalb dauernd meine Tabs durcheinander.

Übrigens benutzt das DXUT auch GetCursorPos(). Und GetForegroundWindow(). Und GetTickCount(), letzteres aber legal.

Krishty hat geschrieben:Der smaller Type Check von VC++ löst da aus.

Wenn man das DXUT mit smaller Type Check kompiliert, fliegen einem auch die Assertions um die Ohren. War bereits als Mist von mir tituliert worden.

Nur damit man mal sieht, was für Code da draußen rumfliegt.

Ich dachte, ein Präprozessor wäre eine vergleichsweise einfache Angelegenheit. Pustekuchen, gegen diese ganze String-Expansion mit Reallokationen und wechselnden Bereichszeigern ist das Aufbauen eines AST ein Kinderspiel. Wie ich da jetzt noch stabile Datei- und Zeilenzuordnung für vernünftige Fehlermeldungen reinbekomme, muss ich wohl morgen rausfinden.

CodingCat hat geschrieben:Wie ich da jetzt noch stabile Datei- und Zeilenzuordnung für vernünftige Fehlermeldungen reinbekomme, muss ich wohl morgen rausfinden.

Speicher einen Zeiger auf die Originaldaten; und falls du Zeile und Spalte brauchst, zähl vom Anfang der Datei bis zu diesem Zeiger. Die Information beim Parsen mitzuschleppen verkompliziert bloß alles (optimize the common case – Fehler und Warnungen sind Ausnahmen und tauchen im Vergleich zu restlichen Symbolen mit einer 1:1000000-Verteilung auf!); außerdem brauchst du für Clang-artige Fehlermeldungen den Originalquelltext. (Stell dir mal vor, wie toll VCs 'geschlossene Klammer vergessen'-Fehler aussähe, wenn er die Einrückung des Quelltexts als Hinweis beachten würde!)

Krishty hat geschrieben:

CodingCat hat geschrieben:Wie ich da jetzt noch stabile Datei- und Zeilenzuordnung für vernünftige Fehlermeldungen reinbekomme, muss ich wohl morgen rausfinden.

Speicher einen Zeiger auf die Originaldaten; und falls du Zeile und Spalte brauchst, zähl vom Anfang der Datei bis zu diesem Zeiger. Die Information beim Parsen mitzuschleppen verkompliziert bloß alles (optimize the common case – Fehler und Warnungen sind Ausnahmen und tauchen im Vergleich zu restlichen Symbolen mit einer 1:1000000-Verteilung auf!); außerdem brauchst du für Clang-artige Fehlermeldungen den Originalquelltext. (Stell dir mal vor, wie toll VCs 'geschlossene Klammer vergessen'-Fehler aussähe, wenn er die Einrückung des Quelltexts als Hinweis beachten würde!)

GCC's Präprozessor spuckt Dateien aus, bei denen immer die Zeilennummern in der Form "#4" und die zugehörigen Dateien in der PP-Ausgabe mit landen und der darauffolgende Compiler den Ursprung einer Zeile wiederherstellen kann.

antisteo hat geschrieben:GCC's Präprozessor spuckt Dateien aus, bei denen immer die Zeilennummern in der Form "#4" und die zugehörigen Dateien in der PP-Ausgabe mit landen und der darauffolgende Compiler den Ursprung einer Zeile wiederherstellen kann.

Ja, genau das soll auch hier am Ende rauskommen, der Zielcompiler fxc unterstützt nämlich ebenfalls #line-Direktiven.

Jammer: Ist die Verbindung zum MSDN bei euch auch so kriechend lahm? Ich sterbe jedes Mal, wenn ich für MSBuild wieder durch die spärliche aber gut verteilte Referenz suchen muss.

Jammer: std::future hat keinen Default-Konstruktor. Man kann also nicht sowas machen wie:
und ich frage mich, warum. Jetzt muss ich das Future mit new anlegen, nur damit der Compiler Ruhe gibt.

emplace_back()?

Der Future ist Teil der Struktur, aber das std::async wird erst später angestoßen. Ansonsten aber gute Idee.

Schrompf hat geschrieben:Jammer: std::future hat keinen Default-Konstruktor. Man kann also nicht sowas machen wie:

Code: Alles auswählen

std::vector<Zeugs> warteStapel;
warteStapel[3].mFutureDingens = std::async( []() { return MachWas(); } );

und ich frage mich, warum. Jetzt muss ich das Future mit new anlegen, nur damit der Compiler Ruhe gibt.

Hm, ist das eine Eigenheit von VC2010? Laut cppreference hat std::future einen Default-Konstruktor, in VC2012 kann ich auch ein Future-Objekt per Default Construction anlegen.

Schrompf: Hast du mal nachgesehen, bzw. in welcher Umgebung entwickelst du gerade?

Umgebung ist VS2012. Ich habe es jetzt nochmal ausprobiert und ihr habt Recht: der Default-Konstruktor ist gar nicht das Problem. Wenn man genau liest, besagt die Fehlermeldung nämlich, dass der Kopierkonstruktor von std::future privat ist. Der wird wahrscheinlich innerhalb von std::vector verwendet, z.B. bei Reallokationen. Ich probiere jetzt einfach mal, einen Move-Konstruktor in der Struktur anzubieten, vielleicht komme ich dann ohne das Zeiger- und new-Gedöns aus.

Schrompf hat geschrieben:Umgebung ist VS2012. Ich habe es jetzt nochmal ausprobiert und ihr habt Recht: der Default-Konstruktor ist gar nicht das Problem. Wenn man genau liest, besagt die Fehlermeldung nämlich, dass der Kopierkonstruktor von std::future privat ist. Der wird wahrscheinlich innerhalb von std::vector verwendet, z.B. bei Reallokationen. Ich probiere jetzt einfach mal, einen Move-Konstruktor in der Struktur anzubieten, vielleicht komme ich dann ohne das Zeiger- und new-Gedöns aus.

Jep, der Move-Konstruktor und evtl. Move-Assignment-Operator sind genau das was du brauchst. Ein echter Jammer, dass VC2012 noch immer nicht dieses trivialste und wichtigste aller Features namens = default anbietet.

Joa, damit geht es auch. Ganz schön mühsam, das Ding manuell zu schreiben. Randfrage: was macht der "= default"-Move-Konstruktor mit Zeigern? Nullt er die, swappt er die mit dem Empfänger, oder lässt er sie unangetastet?

Für eingebaute Typen ist Movement gleichbedeutend mit Kopie, hinterher haben also beide Objekte denselben Zeiger. Wenn das ein Problem ist, hat man in der Regel ohnehin einen Smart Pointer, der dann von sich aus einen korrekten Move-Konstruktor/-Zuweisungsoperator anbietet. Sollte dir das zuwider sein, bleibt a) manueller Move-Konstruktor (will man bei großen Strukturen auf keinen Fall, auch wenn einem momentan nichts anderes übrig bleibt) oder b) Pointer-Wrapper, wobei man wohl in der Regel versuchen würde, diesem Wrapper auch gleich die Destruktion zu übertragen (schlimmstenfalls eigener Smart Pointer, bestenfalls eigener Deleter für unique_ptr). Billiglösung wäre, einen Pointer-Wrapper zu schreiben, der nur das Nullen bei Move/Move-Assignment automatisiert - allgemein nicht zu empfehlen, weil die vollständige Übertragung der Verwaltungsaufgaben an einen Pointer-Wrapper auch gleich zu korrektem Exception Handling führt.

Verstehe. Danke für die Erklärung. Eine schlichte Kopie des Zeigers reicht mir hier, daher ist das ok. Bzw. wäre es ok, wenn VS2012 dieses Feature unterstützen würde :-(

Jap, durch das Weglassen von Default-Move-Konstruktoren und -Operatoren haben sie sich gleich mal mächtige Breaking Changes für ihre zukünftigen Compiler eingehandelt. Ganz davon abgesehen, dass sie unzählige Benutzer zu vollkommen überflüssigem und mächtig fehleranfälligem Code zwingen.

Weitergejammert: Da will ich nach meinen alten Qt Posts suchen und phpBB ignoriert einfach alle Suchwörter mit weniger als 3 Zeichen ("kommt zu häufig vor").

signed __int64 foo = …;
signed __int64 bar = …;
if(foo > 0 && bar > 0) {
    auto x = foo / bar;
}

VS 2010 begreift bei der Division nicht, dass die Typen unsigned sind. Besonders heftig ist das in der 32-Bit-Version, wo das viel langsamere _alldiv() aufgerufen wird und der Maschinentext so fett wird, dass sogar schon das Inlining ausbleibt. Ich darf also alle diese Stellen suchen und von Hand zu unsigned casten.

Zu Hause werde ich mal testen, ob 2012 das ebenfalls verbockt.

Rellocation statt Move funktioniert bei weitem nicht für alle std::string-Implementierungen. STLport speichert beispielsweise einen Zeiger auf den inneren statischen Puffer für Small String Optimization, welcher nach dem ersten Realloc mit großer Sicherheit ungültig ist. Bei der MSVC STL gibt es hingegen ohne Iterator Debugging keine Probleme, weil dort dieser Zeiger immer wieder neu aus this berechnet wird. Mit Iterator Debugging werden intern irgendwelche Debug Proxies auf den Heap gelegt, welche selbst wieder zurück auf das String-Objekt verweisen und somit auch ein ordentliches C++11 Move erfordern.

Fazit: Ich brauche über kurz oder lang auch noch eine eigene Stringklasse. :-/

Krishty hat geschrieben:signed __int64 foo = …;
signed __int64 bar = …;
if(foo > 0 && bar > 0) {
    auto x = foo / bar;
}

VS 2010 begreift bei der Division nicht, dass die Typen unsigned sind. [...]

Hier hätte man sich gewünscht, dass sie den HLSL-Compiler, der ja offensichtlich aus MSVC6 hervorgegangen sein muss, auch wieder so weit zurückportiert hätten, dass die Wertebereiche zu jedem Zeitpunkt vollständig bekannt sind.

CodingCat hat geschrieben:Fazit: Ich brauche über kurz oder lang auch noch eine eigene Stringklasse. :-/

Es gibt ja nicht schon genug string-Klassen ... (auch wenn ich deinen Punkt verstehe)