Jammer-Thread

[eXile]

Ich hatte gerade einen Driver-Bug.

First-chance exception at 0x000007fefd6dcacd (KernelBase.dll) in .exe: Microsoft C++ exception: _com_error at memory location 0x0025e800..
First-chance exception at 0x000007fefd6dcacd (KernelBase.dll) in .exe: Microsoft C++ exception: _com_error at memory location 0x0025e760..
First-chance exception at 0x000007fefd6dcacd (KernelBase.dll) in .exe: Microsoft C++ exception: _com_error at memory location 0x0025eaa0..
First-chance exception at 0x000007fefd6dcacd (KernelBase.dll) in .exe: Microsoft C++ exception: _com_error at memory location 0x0025e800..
First-chance exception at 0x000007fefd6dcacd (KernelBase.dll) in .exe: Microsoft C++ exception: _com_error at memory location 0x0025e760..

In jedem Frame schmierte der Treiber ab, und musste nach zwei Sekunden vom Watchdog neugestartet werden. Spaß. Ich bin froh, dass ich das Fenster noch abschießen konnte.

[Artificial Mind]

Systemupdate... AngelScript kompiliert nicht mit gcc 4.7 ...

[BeRsErKeR]

Scheiß CHM-Komprimierung ... zum Kotzen ...

[CodingCat]

Wie wunderbar, wenn es einfache Lösungen gibt ... ;)

[eXile]

Dürfte ich fragen, für welche Werte von \($a$\) die Lösung relevant ist? Z.B. gibt es für \($a > \frac{3}{2}$\) drei Lösungen:

[Krishty]

Vorhin kamen alle versäumten SMSen der letzten Tage an, nachdem ich mein Handy neu gestartet hatte.
Ich weiß nicht, ob es am Netz oder am Handy lag, aber da das Handy seit einem Monat nicht abgeschaltet wurde, und die Nachrichten keine zwei Minuten nach dem Boot eintrudelten, halte ich einen Programmfehler im Handy für am wahrscheinlichsten. Echt zum Kotzen. (Anrufe gingen übrigens.)

Mein PlayStation 2-Controller schickt unentwegt Input, viele Mal pro Sekunde, obwohl sich nichts geändert hat. Ich weiß nicht, ob das bei den Controllern immer so ist oder am PS-to-PC-Adapter liegt. Es gibt mir jedenfalls ein unangenehmes Gefühl.

Das Gegenteil ist aber auch nicht gut: Mein Joystick sendet nur, wenn sich was ändert. Das bedeutet, dass ich beim Programmstart kurz pollen muss, um seinen Zustand abzufragen — sonst reagierte das Programm nicht auf den Joystick, bevor man ihn zum ersten Mal bewegt; das wäre ziemlich hässlich.

RawInput verlangt von mir eine dynamische Allokation pro WM_INPUT-Nachricht. Man kann sie folgendermaßen umgehen:

• Die Größe der Reports eines HIDs ist konstant. Beim Start der Anwendung (oder, sobald ein neues Gerät angeschlossen wird) enumeriert man alle angeschlossenen Geräte.
• Mit den Preparsed Data (also der Protokolldefinition) ruft man HidP_GetCaps() auf. Damit bekommt man die Eigenschaften des HIDs angezeit, wozu auch die Größe eines Reports gehört.
• Von allen Reportgrößen bestimmt man das Maximum. Dazu berechnet man die Unkosten durch RawInput-Header, die vor dem Report platziert werden.
• Einen Speicherbereich dieser Größe allokiert man einmal und nutzt ihn, um die Daten jeder WM_INPUT zu empfangen.

[eXile]

Code: Alles auswählen

static size_t const numberIndices = 
    std::extent<decltype(indices)>::value *
    std::extent<decltype(
        static_cast<std::remove_extent<decltype(indices)>::type *>(nullptr)->theIndices
    )>::value;

Hier gibt es nicht das Geringste zu sehen. Bitte gehen Sie weiter.

[glassbear]

Bloeder Steam-Summer-Sale. Hab eindeutig zu viel gekauft :lol:

[Schrompf]

Joa, gut, dass der Steam Sale vorbei ist. Hab meine Sammlung von Spielen auf Vorrat heftig erweitert, ohne dass sich meine Chancen, meinen Rückstand aufzuholen, nennenswert verbessert hätten. Das wiederrum liegt an Battlefield 3, womit ich meine abendliche Zockzeit nun primär verbringe.

Auch was gejammert: es ist erstaunlich kompliziert, einen Textursampler mit bilinearem Filter selbst zu schreiben. Modulo und Konsorten sind um den Nullpunkt rum furchtbar inkonsistent. Mein aktueller Code dafür ist nun voll mit floor() und Konsorten... wahrscheinlich gibt es dafür auch einen eleganten Weg, aber ich finde ihn nicht.

[eXile]

[Artificial Mind]

[eXile]

Habe gerade die A new dawn-Demo ausprobiert. Begeisterungsgrad: Medium.

[Krishty]

Verdammter Intel-Chipsatz im Eee PC kriegt Clipping nicht richtig gebacken. Flach aufs Terrain gucken flimmert die Scheiße heraus aus dir. Es ist zum Kotzen, dass man sowas Fundamentales verkacken kann. Ich habe hier ein niedrig aufgelöstes Mesh als Landschaft und während man sich drüberbewegt wird wortwörtlich der halbe Bildschirm von Einzelbild zu Einzelbild abwechselnd himmelblau und dann wieder felsdunkel. I can't even …

Warum ist beim Erstellen einer Antwort hier auf ZFX der Eingabefokus nicht im Antwortfeld? Ich habe hier bloß ein Touchpad, das außerdem fast einen Meter von mir wegsteht. Ich will ALLES via Tastatur bedienen können. Was wollt ihr denn machen wenn ein körperlich schwer Behinderter auf ZFX Rants über falsch implementiertes Clipping in den Jammer-Thread klatschen will? "Dummes ZFX. Lässt mich nicht meine Antwort eingeben."

[kaiserludi]

Warum ist beim Erstellen einer Antwort hier auf ZFX der Eingabefokus nicht im Antwortfeld? Ich habe hier bloß ein Touchpad, das außerdem fast einen Meter von mir wegsteht. Ich will ALLES via Tastatur bedienen können. Was wollt ihr denn machen wenn ein körperlich schwer Behinderter auf ZFX Rants über falsch implementiertes Clipping in den Jammer-Thread klatschen will? "Dummes ZFX. Lässt mich nicht meine Antwort eingeben."

Bei Schnellantwort habe ich den Fokus von Anfang an, bei Erweitert nach 2 mal Tab drücken.

[Krishty]

Stimmt, bei Schnellantwort klappt es.

Bei der erweiterten Antwort (die ich zuerst sehe, wenn ich mich zum Antworten einlogge) kann ich nicht einmal sagen, wo der Fokus ist. (Bei den Beitragssymbolen?) Brauchen wir Betreff überhaupt? Benutzt das wer?

[eXile]

Für extended-length-Pfade gilt: Stellt man das \\?\ einem Pfad voran, welcher / als Separator enthält, so schlägt CreateFile fehlt. Dahingegen klappt es bei Pfaden mit \ als Separator problemlos.

[BeRsErKeR]

Für extended-length-Pfade gilt: Stellt man das \\?\ einem Pfad voran, welcher / als Separator enthält, so schlägt CreateFile fehlt. Dahingegen klappt es bei Pfaden mit \ als Separator problemlos.

Note File I/O functions in the Windows API convert "/" to "\" as part of converting the name to an NT-style name, except when using the "\\?\" prefix as detailed in the following sections.

...

For file I/O, the "\\?\" prefix to a path string tells the Windows APIs to disable all string parsing and to send the string that follows it straight to the file system.

Quelle: http://msdn.microsoft.com/en-us/library ... s.85).aspx

[eXile]

Lustig, die Seite hatte ich bestimmt schon zehnmal gelesen, aber irgendwie haben ich die betreffenden Stellen immer überlesen. Besten Dank für den Link. Lustigerweise klappt es im Windows Explorer unabhängig vom verwendeten Separator.

[kaiserludi]

Ich habe folgenden Code:

Code: Alles auswählen

template<typename CType> struct ConfirmAllowedType;
template<> struct ConfirmAllowedType<short>
{
	typedef short type;
};

Code: Alles auswählen

class Foo
{
public:
	void doSomething(void);
	template<typename FType> void doSomething(typename ConfirmAllowedType<FType>::type param);
};

Ein Versuch, die template-Funktion aufzurufen, führt nun unter MCVC++ zur Fehlermeldung "error C2660: 'Foo::doSomething' : function does not take 1 arguments".

Offensichtlich sieht der Compiler also nur die einfache Funktion, nicht aber die Templatefunktion.

Nach ein wenig Herumspielen mit der Klasse weiß ich, dass

Code: Alles auswählen

class Foo
{
public:
	void doSomething(void);
	template<typename FType> void doSomething(int param);
};

mir die gleiche Fehlermeldung einbringt, wähend

Code: Alles auswählen

class Foo
{
public:
	void doSomething(void);
	template<typename FType> void doSomething(FType param);
};

anstandslos kompiliert.

Die Fehlermeldung ist also einfach nur sehr ungünstig, da sie als Folgefehler eines Errors "could not deduce template argument" verhindert, dass der "could not deduce template argument" Fehler überhaupt angezeigt wird.
Bei template<typename FType> void doSomething(int param); ist natürlich klar, dass der Compiler keine Möglichkeit hat an Hand des Aufrufs herauszufinden, für was für einen Typ für FType er die Funktion nun instanziieren soll.
Bei template<typename FType> void doSomething(typename ConfirmAllowedType<FType>::type param); hingegen verfügt er doch über FType in der Signatur, ist aber anscheinend überfordert, den Typ für FType zu ermitteln, wenn er als Parameter statt einem FType ein komplexeres Konstrukt bekommt.

[CodingCat]

Die Fehlermeldung ist also einfach nur sehr ungünstig, da sie als Folgefehler eines Errors "could not deduce template argument" verhindert, dass der "could not deduce template argument" Fehler überhaupt angezeigt wird.

Leider spielen hier viele Sachen mit rein. Zunächst einmal sieht das, was du da versuchst, stark nach SFINAE aus. SFINAE nutzt genau das beschriebene Verhalten, um bestimmte Template-Überladungen in Abhängigkeit von gewissen Eigenschaften der übergebenen Typen an- oder abzuschalten. SFINAE ist aber nur deshalb möglich, weil der Compiler in den von dir gezeigten Fällen keine Fehlermeldungen zu den Funktionen bringt, die aufgrund unvollständiger Angaben zur Deduktion oder ungültiger Signatur durch abhängige Typen nicht kompilierbar wären.

Bei template<typename FType> void doSomething(int param); ist natürlich klar, dass der Compiler keine Möglichkeit hat an Hand des Aufrufs herauszufinden, für was für einen Typ für FType er die Funktion nun instanziieren soll.
Bei template<typename FType> void doSomething(typename ConfirmAllowedType<FType>::type param); hingegen verfügt er doch über FType in der Signatur, ist aber anscheinend überfordert, den Typ für FType zu ermitteln, wenn er als Parameter statt einem FType ein komplexeres Konstrukt bekommt.

Nein, der Compiler ist nicht überfordert, sondern der Sprachstandard schränkt Deduktion explizit ein. Das, was du hier tust, sieht zwar in dieser Form aus, als wäre es trivial lösbar. Tatsächlich bieten Templates aber mit (partiellen) Spezialisierungen schlichtweg zu viele Freiheitsgrade, um derartige Konstrukte im allgemeinen Fall zuverlässig und eindeutig auflösen zu können.

Eine korrekte Fassung dessen, was du hier versuchst, sieht wie folgt aus:

Code: Alles auswählen

template<typename CType> struct ConfirmAllowedType { static const bool value = false; };
template<> struct ConfirmAllowedType<short> { static const bool value = true; };

// enable_if ist Teil von C++11!
template <bool B, class T = void> struct enable_if;
template <class T> struct enable_if<true, T> { typedef T type; };

class Foo
{
public:
        void doSomething(void);
        template<typename FType> typename enable_if<ConfirmAllowedType<FType>::value>::type doSomething(FType param);
};

Diese Variante nutzt genau das Verhalten, dass eine ungültige Signatur aufgrund eines gegebenen FType keinen Fehler verursacht, sondern die Überladung in diesem Fall einfach ignoriert wird.

Eine andere Variante, näher an deiner, wäre:

Code: Alles auswählen

template<typename CType> struct ConfirmAllowedType;
template<> struct ConfirmAllowedType<short> { typedef short type; };

template <class B, class T = void> struct enable_on { typedef T type; };

class Foo
{
public:
        void doSomething(void);
        template<typename FType> typename enable_on<ConfirmAllowedType<FType>::type>::type doSomething(FType param);
};

Noch eine andere Variante:

Code: Alles auswählen

template<typename CType> struct ConfirmAllowedType;
template<> struct ConfirmAllowedType<short> { typedef short type; };

class Foo
{
public:
        void doSomething(void);
        template<typename FType> void doSomething(FType param, typename ConfirmAllowedType<FType>::type* = nullptr);
};

[kaiserludi]

Meine Lösung vorhin war, statt typename ConfirmAllowedType<FType>::type weiterhin einfach nur FType zu übergeben und dann in der ersten Zeile im Body der Funktion, in der ich eh für einen statischen Assert auf ein static Member von FType zugegriffen habe, statt FType nun ConfirmAllowedType<FType>::type zu verwenden, da ie Deduktion an der Stelle ja schon erfolgt ist und der ganze Zweck hinter ConfirmAllowedType eh nur ist, die Verwendung nicht unterstützter Typen bereits zur Compilierzeit und nicht erst zur Laufzeit abzufangen.

Deine Varianten sehen allerdings auch interessant aus. Nur: In den ersten beiden Fällen habe ich dann ja einen Rückgabewert, den auch irgendwer auslesen könnte, im letzten Fall einen zusätzlichen Parameter, bei dem auch jemand versuchen könnte, was anderes als den Default zu übergeben, sprich ich verkompliziere quasi in allen 3 Fällen das Interface mit Dummies, bei denen ein Aufrufer sich erst wieder im Klaren sein muss, daass es sich um Dummies handelt.

PS:
Müsste typename ConfirmAllowedType<FType>::type* = nullptr nicht typename ConfirmAllowedType<FType>::type* someExtremelyCoolParameterName = nullptr heißen?

[CodingCat]

Meine Lösung vorhin war, statt typename ConfirmAllowedType<FType>::type weiterhin einfach nur FType zu übergeben und dann in der ersten Zeile im Body der Funktion, in der ich eh für einen statischen Assert auf ein static Member von FType zugegriffen habe, statt FType nun ConfirmAllowedType<FType>::type zu verwenden, da ie Deduktion an der Stelle ja schon erfolgt ist und der ganze Zweck hinter ConfirmAllowedType eh nur ist, die Verwendung nicht unterstützter Typen bereits zur Compilierzeit und nicht erst zur Laufzeit abzufangen.

Okay, dann wäre ein static_assert(ConfirmAllowedType<FType>::value, "Given FType not allowed") aber vermutlich hilfreicher als irgendein Fehler durch die Referenzierung eines nicht existenten abhängigen Typnamens, hier ConfirmAllowedType<FType>::type.

Deine Varianten sehen allerdings auch interessant aus.

Dein Anwendungsfall unterscheidet sich aber stark von dem, was ich hier gezeigt habe. Während durch static_assert bzw. Referenzierung im Funktionsrumpf immer eine Fehlermeldung ausgelöst wird, kommt es in den von mir gezeigten Varianten gerade zu keiner Fehlermeldung; stattdessen werden dort die fehlerhaften Überladungen einfach stillschweigend abgeschaltet.

Nur: In den ersten beiden Fällen habe ich dann ja einen Rückgabewert, den auch irgendwer auslesen könnte, im letzten Fall einen zusätzlichen Parameter, bei dem auch jemand versuchen könnte, was anderes als den Default zu übergeben, sprich ich verkompliziere quasi in allen 3 Fällen das Interface mit Dummies, bei denen ein Aufrufer sich erst wieder im Klaren sein muss, daass es sich um Dummies handelt.

Nein, der Rückgabetyp ist in allen drei Fällen void. Und ja, der zusätzliche Parameter in der Anwenderschnittstelle ist unschön. Ich habe die Variante hier der Vollständigkeit halber aufgeführt, weil es sich hierbei gewissermaßen und den Low-Level-Basisfall von SFINAE handelt. Insbesondere lässt sich damit eine Fülle von Helfer-Templates zur Analyse von Typeigenschaften formulieren. Davon abgesehen ist der Dummy-Parameter bei Konstruktoren manchmal unvermeidbar, weil diese keinen Rückgabetypen besitzen.

PS: Müsste typename ConfirmAllowedType<FType>::type* = nullptr nicht typename ConfirmAllowedType<FType>::type* someExtremelyCoolParameterName = nullptr heißen?

Wenn du den Parameter benennen willst; ohne Name wird aber eventuell deutlicher, dass es sich um keinen echten Parameter handelt.

[kaiserludi]

Ah, mir war gar nicht klar, dass default values auch für unbenannte Parameter funktionieren.

[kaiserludi]

"fatal error C1128: number of sections exceeded object file format limit : compile with /bigobj"

18.435 aus einem Template instantierte Klassen, die wiederum die Instantierung von über 100.000 Klassen aus anderen Templates getriggert haben -> "autsch".

[Krishty]

Bin durch eine Grippe außer Gefecht gesetzt und nächstes Wochenende nicht in der Nähe des Internets; der Artikel über HID muss deshalb noch eine oder zwei Wochen warten. Entschuldige, Schrompf.

[Schrompf]

Du bist mir nichts schuldig. Alles ist also gut. Lass Dich nicht unterkriegen!

[Krishty]

Das scheiß Find & Replace-Fenster von Visual C++ 2010 ist saulahm. Ich klicke auf den Solution Explorer – sofort da. Ich klicke Strg+F – drei Sekunden Verzögerung, während sich das Fenster langsam aufbaut, das aus nichts besteht als aus einem Eingabefeld, einem Auswahlfeld, zwei Checkboxen und zwei Knöpfen. Mitunter ist Go to Definition schneller. WTF, Microsoft. WTF.

[Jonathan]

Suchen geht bei mir eigentlich recht schnell, aber ich bin regelmäßig schneller, Definitionen per Hand zu finden, als per Schnelltaste. Weil er einfach ewig rechnet und mir dann oft 10 Vorschläge gibt, von denen 9 total absurd sind.
Ansich warte ich einfach nur noch darauf, dass libclang in Eclipse oder QtCreator integriert wird und rund läuft, dann verabschiede ich mich von VC. Langsam reicht es.

[kaiserludi]

Eclipse und QTCreator? Das sin doch die beiden IDEs mit den mit Abstand schlechtesten UIs am Markt. Grausig, ich bin über jede Sekune meines Lebens froh, in denen ich diese beiden nicht anrühren muss und stattdessen VS oder Xcode nutzen kann.

[Chromanoid]

Irre wie sich da die Geister scheiden, ich würde XCode nicht mal mit der Kneifzange anfassen :)