ZFX + Developia

Meine anderen beiden Visual-C++-Fehlermeldungen sind auch kommentarlos als zurückgestellt geschlossen worden (ich weiß es nicht genau, aber vermute, dass sich die Zuständigen währenddessen gegenseitig einen auf Wolkendiagramme runtergeholt haben). Ich schließe daraus, dass ich die in Zukunft penetranter nerven muss.

    for(currentBase = 10000u; currentBase > 0u; currentBase /= 10u) {

Visual C++ kann nicht vorhersagen, dass diese Schleife fünf Mal durchlaufen wird. Langsam kriege ich Angst.

Krishty hat geschrieben:    for(currentBase = 10000u; currentBase > 0u; currentBase /= 10u) {

Visual C++ kann nicht vorhersagen, dass diese Schleife fünf Mal durchlaufen wird. Langsam kriege ich Angst.

Kanns denn der GCC oder clang?

Clang werde ich leider erst Montag wieder haben, dann probiere ich es wieder. GCC-kompatibel ist der Quelltext leider nicht.

http://gcc.godbolt.org/#%7B%22version%2 ... 2%7D%5D%7D

;)

Demnach bekommt GCC es aufgelöst, aber nur bis zu 7 Iterationen. In meinem Fall (String-Formatierung) reicht es also sogar dort nicht aus, ein unsigned int statisch als Dezimal-String auszugeben, sondern unsigned short ist das Limit :( Aber immernoch besser als VC.

Hehe, das ist ziemlich cool. Nicht nur, dass es so einen online Compiler gibt, sondern auch dass clang es so hübsch optimiert :)

Ich kann es nicht testen; habe zwar die Exception Handler rausgepopelt, aber die LTCG schmiert bei mir ab :(

3,5 Stunden debuggen, nur weil
http://www.opengl.org/sdk/docs/man/xhtm ... mage2D.xml
verschweigt, dass für format auch sowas wie GL_RED_INTEGER möglich ist, und für Integer-Texturen auch zwingend gefordert wird.

Jonathan hat geschrieben:3,5 Stunden debuggen, nur weil
http://www.opengl.org/sdk/docs/man/xhtm ... mage2D.xml
verschweigt, dass für format auch sowas wie GL_RED_INTEGER möglich ist, und für Integer-Texturen auch zwingend gefordert wird.

Exakt das Gleiche ist mir auch schon mal passiert. Man findet es einfach nicht.

Ich habe denen über das Feedback-Formular mal eine Mail geschickt. Mal sehen, ob sich da was tut. Denn ansonsten ist die OpenGL Doku eigentlich ganz schön, wäre schade, wenn die sowas nicht fixen würden.

Ich habe heute entdeckt, dass jemand den Draw()-Aufruf unserer Renderer-Schnittstelle (der, der unter Direct3D zu DrawIndexedPrimitive() evaluieren sollte) als 225-zeilige Funktion implementiert hat. Die Indirektionstiefe der beteiligten Parameter lag zwischen 3 und 7.

Es ist niederschmetternd, dass die schiere Masse an Maschinentext, die es auf der Welt gibt, zu groß ist, als dass ich sie in meinem Leben refactoren könnte.

MSDN hat geschrieben:Sammeln Sie

Berechnet die Summe aller Elemente in einem angegebenen Bereich einschließlich einige Anfangswert, indem das Ableiten von aufeinander folgenden partiellen Summen oder berechnet das Ergebnis der aufeinander folgenden partiellen Ergebnisse abgerufenen auf ähnliche Weise von der Anwendung einer angegebenen binären Operation als die Summe.

Ich liebe automatisch übersetzte Beiträge. Für Neugierige: das ist der Hilfetext zu std::accumulate(). Wer wär drauf gekommen?

Das hasse ich so abgrundtief an der MSDN. Wie endlos bescheuert sind die Leute, die da sitzen, unsere (um beim Thema zu bleiben) akkumulierte Lebenszeit damit zu verschwenden, dass wir bei jedem Artikel erstmal den Schalter suchen müssen, der uns zum englischen Original bringt?

Abgesehen davon, dass maschinelle Übersetzungen von Artikeln, bei denen man den exakten Wortlaut interpretieren muss, wie Hämhorroiden-Creme auf Brötchen ist – nämlich eigentlich für’n Arsch – könnte ich zwar die Existenz japanischer, chinesischer und russischer Versionen verstehen, weil diese Sprachen krass anders sind; aber zu denken, dass ein deutscher Programmierer kein Englisch kann, und uns dafür alle mit diesem scheiß Kauderwelsch zu bestrafen, ist debil.

Meine externe Festplatte ist nicht angeschlossen, sonst hätte ich meiner Empörung durch oszöne GIFs Ausdruck verliehen.

Als kurze Anmerkung dazu: Das ist übrigens rein von dem Locale im User-Agent, der vom Browser verschickt wird, abhängig. Ändert man den Locale mit Addons für die MSDN auf en-US, dann ist automatisch alles auf Englisch. Was natürlich jetzt nichts an der grenzdebilen Entscheidung ändert, überhaupt maschinell übersetzte Artikel anzubieten.

Ich baue mir gerade die CRT nach, und bin bei der Ausnahmebehandlung. Ich habe es geschafft, passende try- und catch-Blöcke zu identifizieren; habe die Laufzeittypinformationen abgeglichen; habe die geworfenen Objekte kopiert (sogar falls polymorph) – aber beim Stack Unwinding wird eine Zugriffsverletzung ausgelöst.


Danach existiert kein Stack mehr; ich kann also nicht einmal sehen, wo der Prozess auseinanderbricht. Die direkten Parameter sind identisch zur CRT-Implementierung. Jetzt kann ich also 2000 Zeilen Quelltext, den ich nicht verstehe, durchgehen und jedes Zwischenergebnis mit dem der CRT vergleichen um den Fehler zu suchen.

Meh, manchmal ist C++ so fummelig. Seit C++11 soll ich jetzt pro Klasse einen Konstruktor, Destruktor, Copy-Ctor, Zuweisungsoperator, Move-Ctor und Move-Zuweisungsoperator schreiben? Und muss möglicherweise bei jedem neuen Member alle 5 anpassen, und wehe ich vergesse mal einen? meh...

Die Boss Gegner verderben mir meinen "Tell-Me-a-Story" Modus von Deus Ex 3...

Jonathan hat geschrieben:Meh, manchmal ist C++ so fummelig. Seit C++11 soll ich jetzt pro Klasse einen Konstruktor, Destruktor, Copy-Ctor, Zuweisungsoperator, Move-Ctor und Move-Zuweisungsoperator schreiben? Und muss möglicherweise bei jedem neuen Member alle 5 anpassen, und wehe ich vergesse mal einen? meh...

Das liegt aber ausschließlich an den unfähigen Pfeifen bei MS. Tatsächlich sollst du in C++11 für Aggregationen allenfalls eigene Konstruktoren schreiben, wenn spezielle Initialisierung notwendig ist (ohne eigene Konstruktoren erlaubt C++11 praktisch überall Initialisierung via Initializer-List!). Alles andere generiert der Compiler für dich (sofern er nicht Visual C++ heißt, bah!). Erlauben alle Members Kopie, Zuweisung, Move Construction oder Move Assignment, so werden automatisch alle möglichen entsprechenden Konstruktoren und Operatoren generiert. Nur Visual C++ kann noch immer keine impliziten Move-Funktionen; dass Variadic Templates noch zuvor kommen, ist einfach nur lachhaft.

C++11 hat im Übrigen auch einen wunderbar schlüssigen Regelsatz für die wenigen Fälle, in denen Kopie/Movement händisch implementiert werden muss (das sollte in der Regel immer nur der Basisfall sein, also sowas wie unique_ptr; Aggregationen sollten derartige Verantwortung an die Typen ihrer Members übertragen und sich auf die implizite Generierung verlassen). So deaktiviert händisch implementierte Movement-Funktionalität automatisch die implizite Kopierfunktionalität und umgekehrt, bis die jeweilige ebenfalls händisch implementiert wurde, oder explizit per = default reaktiviert wurde. Weiterhin deaktiviert ein Destruktor implizite Movement-Funktionalität (Kopierfunktionalität ist in diesem Fall deprecated, was die Compiler bis jetzt leider einen feuchten Kehricht kümmert). Auch hier kann per = default notwendige Funktionalität wieder angeschaltet werden.

Wie wir sehen, ist C++11 ein gigantischer Schritt in die richtige Richtung, der uns allen einen riesen Haufen unnötiger Schreibarbeit, potentieller Inkonsistenz und Redundanz ersparen könnte, wenn VC++ sich endlich herablassen würde, diesen zu implementieren. Dann haben die meisten Klassen tatsächlich nicht mehr als einen Konstruktor; viele nicht mal das (Default Construction lässt sich ab C++11 direkt per Zuweisung bei der Member-Deklaration durchführen; Dateninitialisierung per Initializer-List).

Vorsicht ist in VC++ obendrein geboten, wenn man notgedrungen völlig unnötige Move-Konstruktoren und -Zuweisungsoperatoren implementiert, aus gesundem Menschenverstand aber dennoch von der impliziten Generierung des Kopierkonstruktors Gebrauch macht. Entsprechend den eben ausgeführten Regeln heißt das für die Zukunft, dass der implizite Kopierkonstruktor irgendwann als deaktiviert gilt. Also um jeden schmerzhaft händisch implementierten Standard-Move-Konstruktor bzw. -Zuweisungsoperator noch ein #ifdef, dass die händischen Varianten in zukünftigen Compilern zugunsten der implizit generierten deaktiviert und damit auch den Kopierkonstruktor wieder aktiviert.

Dieses Chaos wurde ihnen präsentiert von Microsoft. Your obstruction. Our passion. Aber irgendwann wird alles gut, und wir müssen uns nie wieder um Konstruktoren und Assignment kümmern.

Das ist, als ob dich einer in den Arm nimmt und sagt, dass alles gut wird :)
thx für die Info, ich freue mich drauf.

Ich will, dass Visual Studio nach 10 Fehlern den Kompiliervorgang abbricht.

Atm ist es wirklich katastrophal: Ich starte den Build; warte 30 Sekunden. Die Scheiße trifft den Ventilator; ich kriege 1000 Syntaxfehler und muss sauschnell cancel build ansteuern.

Jetzt beginnt die Quälerei: Von den 16 Prozessen, in denen kompiliert wird, bleiben dauernd 4 oder 5 hängen; manchmal über 20 Sekunden, manchmal über Minuten. Während eines Builds sind Find & Replace und ähnliche Funktionen deaktiviert; ich kann also effektiv nicht arbeiten bis die Build-Prozesse weg sind. Ich muss die dann manuell beenden.

Für das manuelle Abwürgen habe ich mir mittlerweile eine Verknüpfung C:\Windows\System32\killtask /f /im cl.exe in die Task-Leiste gelegt. Trotzdem kotzt es mich saumäßig an, dass wenn ich kurz aufstehe und wiederkomme, 30k Zeilen Fehler im Output-Log stehen. Bah.

Ja, das nervt mich auch. Suchen&Ersetzen geht bei mir noch beim Build, aber bei Benutzung von Edit&Continue habe ich eine 20%e Chance, dass der erste Klick die komplette IDE einfriert. Ganz zu schweigen von x Zombie-Threads, die sich so nach und nach ansammeln. Und trotz Buildfehlern baut der Trottel weiter... und das Unterbrechen ist bei LTGC bestenfalls eine Glückssache, manchmal braucht es nur ne kleine Ewigkeit zum Abbrechen, manchmal crasht es die ganze IDE.

Ich frage mich, womit Microsoft seine Programme schreibt. Mit VC wahrscheinlich nicht, dann wäre der desolate Zustand schonmal jemandem aufgefallen.

Boah ich werde noch bekloppt. Warum sind in C++ hunderte Zeilen Templates nötig um sagen zu können, ob ein Typ POD ist?!

JETZT REICHTS.
Wie unfähig sind bitte die Leute die meine Treiber schreiben. (ja, ich fang mal bei meinen Treibern an). Razer Ouroboros: 130€ für eine Maus. Eigentlich ganz schick das Ding, wackelt aber etwas auf meinem Tisch, und ich bin mir sicher dass nicht der Tisch uneben ist. Aber zum Treiber: beim umstecken vom Funkempfänger zur Maus (Akku hält höchstens 8 Stunden :shock:) dauert es ca. 30s bis die Maus wieder erkannt wird, wenn überhaupt. Die Funktion zum runterregeln der DPI: wurde wahrscheinlich ziemlich ausführlich getestet mit dem Ergebniss, sie funktioniert zu gut und wir verkaufen na noch nen paar Käferchen mehr. Anderst kann ich mir nicht erklären wie man so einen "perfekten Random-DPI-Generator" zustande bringt. Und das UNABHÄNGIG in X- und Y-Richtung!!! Sollten sie als Geschicklichkeitsspiel verkaufen und nicht als Gamermaus. Dabei wär das ganze eigentlich so praktisch wenn man mal z.b. in Photoshop was kleineres zeichnen will).
Nach mir wird verlangt. Die "Gute-Nacht-Geschichte" über Catalyst Control Center Desktopfarben und Windows Lautstärkemixer fällt aus oder wird unbestimmt verschoben.

(hat zwar nicht unmittelbar mit Spieleprogrammierung zu tun, aber ich musst das irgendwo loswerden...)
MFG

Krishty hat geschrieben:Boah ich werde noch bekloppt. Warum sind in C++ hunderte Zeilen Templates nötig um sagen zu können, ob ein Typ POD ist?!

Lustigerweise war mir POD immer zu grob-granular; ich selber verwende:

• has_trivial_constructor
• has_trivial_assign
• has_trivial_destructor

Anhand dieser Traits entscheide ich dann, ob ein memcpy reicht, oder man den jeweiligen Konstruktor/Zuweisungsoperator oder überhaupt einen Destruktor aufrufen muss.

Ja; aber ich pflege ja meine eigene STL. Die Compiler stellen Intrinsics à la Microsofts __has_trivial_copy bereit. Das funktioniert dann aber nur für User Types; nicht für built-ins. Ich muss also dann noch ein is_scalar schreiben. Das benötigt dann is_arithmetic, is_enum, is_pointer, is_pointer_to_member, und is_nullptr_t. is_arithmetic benötigt is_integral und is_floating_point. is_integral benötigt is_standard_integer. Und von dort sickert dann durch: „Yup; int darfst du kopieren wie du willst.“.

Kurz: Selbst für deine Vorschläge gehen noch mindestens 50 Zeilen ekliger Template-Metaquatsch drauf, die ein vernünftiges Compiler-Intrinsic locker sparen könnte.

Der Grund, warum <type_traits> so viel zur Verfügung stellt ist nicht Barmherzigkeit, sondern dass alles aufeinander aufbaut, und man für den kleinsten Furz den ganzen Köttel mitimplementieren muss.

Ich habe gerade 40 Cent bei Adwords dafür gezahlt, dass sich ein Nutzer 2 Sekunden lang auf meiner Seite aufgehalten hat.

Und jetzt auch noch 50 Cent, damit sich einer die Seite 4 Sekunden lang anschaut.

Schon praktisch, solche Tracking-Tools, hm?

Auf die Gefahr hin, garstig zu klingen: vielleicht gefällt den Leuten Deine Webseite einfach nicht?

Heute morgen wurde eins meiner Videos auf Youtube wegen Copyright Claims von "Microsoft Corporation" gesperrt.
Von Youtube bekomme ich folgende Daten:
Claimant: Microsoft Corporation
Representative: Navnit Kumar
Claimant Email: microsoft-notices@marketly.com
Wenn man etwas sucht, dann merkt man, dass marketly.com dafür bekannt ist, bogus DMCA claims zu senden (z. B. auf Techdirt).

Ich bin begeistert.
Hab jetzt einfach mal eine freundliche Mail hingeschickt und nachgefragt was genau das Problem ist oder ob ich nicht zufällig Opfer eines false positive geworden bin... so richtig viel Hoffnung habe ich allerdings nicht.