Jammer-Thread

[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 :)

[Artificial Mind]

Ja, das ist tatsächlich Religion. Ich bin ständig am Eclipse bashen und benutze VS für C# und QtCreator für C++ (VS für C++ nur mit Visual Assist X).

[kaiserludi]

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

Xcode ist in den letzen Jahren deutlich besser geworden.

Ja, das ist tatsächlich Religion. Ich bin ständig am Eclipse bashen und benutze VS für C# und QtCreator für C++ (VS für C++ nur mit Visual Assist X).

Ich ziehe selbst VC++ Express um Längen genüber QTCreator vor, aber VAX befördert VS natürlich noch mal in eine neue Dimension.

[Artificial Mind]

Ja, das ist tatsächlich Religion. Ich bin ständig am Eclipse bashen und benutze VS für C# und QtCreator für C++ (VS für C++ nur mit Visual Assist X).

Ich ziehe selbst VC++ Express um Längen genüber QTCreator vor, aber VAX befördert VS natürlich noch mal in eine neue Dimension.

1. Wenn man mit Qt arbeiten muss, ist VC relativ undankbar (bzw. die Integration von Qt im QtCreator ist halt ungeschlagen)
2. Mich stört diese "Filter"-Struktur, statt einer "Ordner"-Struktur in VC++
3. QtCreator kommt besser mit CMake-Projekten klar
4. Linux (ja, ich muss auch auf/für Linux entwickeln)

Ein sauberes C++ Projekt, das mit Visual Studio erstellt ist (lies: kein CMake-Generat), kein Qt beinhaltet und für Windows ausgelegt ist, würde ich wahrscheinlich tatsächlich eher in VC++ schreiben, da das VC++-Intellisense nur unter genau diesen Bedingungen gut funktioniert. (VAX lässt es in der Tat eine Liga aufsteigen, aber das ändert meist nichts an den kaputten CMake-VC-Solutions und schon lange nichts an Linux)

Der QtCreator ist mittlerweile echt ganz gut, die Autovervollständigung ist noch nicht perfekt, aber wenigstens berechenbar.

Hieran sieht man glaube ich ganz gut, dass es stark von den Umständen abhängt.

PS: Ich habe momentan ein C++ Projekt, dass auf Windows 7 ausgelegt ist und das wir in VS 2012 mit VAX entwickeln. Wir benutzen sogar C++/CLR und arbeiten mit WPF im C++ Code und es ist immer noch angenehmes Programmieren.

[eXile]

Ich will dann auch mal meinen Senf dazu schreiben. Ich bin mit Visual Studio eigentlich zufrieden. Visual Assist habe ich mal ausprobiert, aber es hat mich nicht wirklich überzeugt, weil ich die meisten Features nicht gebraucht habe, und gerade das Nützliche, nämlich das lokale Code-Refactoring, bei stark getemplateten Code doch relativ häufig versagt hat.

Das scheint auch irgendwie der Nemesis dieser ganzen Refactoring-Tools zu sein: Kaum sind sie mal mit turing-vollständigen Templates konfrontiert, kollabieren sie zu einem kleinen Häufchen rauchender Asche.

[kaiserludi]

Bei C++/CLR kommt ja eh nur VS infrage. Wobei ich ja immer noch auf objC++/CLR warte. Die Syntax wäre einfach der Hammer ;-)
1. QT setzen wir nicht ein. Daher fällt der Punkt für mich flach. Der QTCreator würde aber wohl auch seinen Namen nicht mehr verdienen, wenn er nicht den besten QT-Support haben würde.
2. Ist mir bisher nicht wirklich negativ aufgefallen.
3. CMake-Projekte rühre ich nur an, wenn es keinen Weg gibt, das ganze nicht auch als natives Projekt der jeweiligen IDE aufzusetzen.
4. Habe auch mal für ein Mobile Linux (Meego) entwickelt. Daher kenn ich den QTCreator. Ich habe diese IDE schnell zu hassen gelernt: Verbuggt und schneckenlahm. Projektsettings ändern: 30Sekunden Wartezeit nach jedem Klick, bevor die IDE wieder reagiert hat. Nun änder da mal 4 Setting pro Konfiguration bei 8 Konfigurationen pro Projekt und 6 Projekten. Schön wars auch immer, wenn der Projektsettingsidalog sich horizontal auf 3 fache Screenauflösung vergrößert hat und man ihn nicht mehr kleiner bekam: Lustiges hin und herschieben. Dazu sind QTCreator-Projektdateien inkompatibel zu sauberer Versionsvewaltung, weil Projekteinstellungen und Sachen wie Timestamps des letzten Öffnens des Projektes in der selben Datei gespeichert werden.

Ich entwickle derzeit für AndroidNDK (VS mit VAX, VS-android und WinGDB), Blackberry (QNX Momentics (gleiche UI wie Eclipse - würg)), iOS (Xcode), Marmalade (VS und Xcode), OS X (Xcode) und Windows (VS) und habe in den letzen Jahren auch für Brew (VS), Meego (QTCreator - argh) und Windows Mobile (VS) entwickelt. Der Code ist über alle Plattformen zu 99% identisch, das bischen plattformabhängiges sauber weggekapselt, aber da eh jede Plattform ihre eigenen Projekte braucht, nehme ich auch die jeweils meinem Empfinden nach brauchbarste kompatible IDE. 95% der Zeit kann ich mich auf VS und Xcode beschränken, wenn VC++ (VS), GCC (VS und Xcode) und Clang (Xcode), die ich damit abdecke, mit dem Code klar kommen, muss ich fast immer nur noch die Projektfiles im Falle neuer Datein anpassen und testweise einen "Build SDKs for all Platfroms" anschmeißen, dann passt alles, zumindest seit wir kein Brew mehr unterstützen. Das war die Hölle: Testdevices nur per Remotezugriff in Übersee, riesige Unterschiede zwischen Devices und Simulator und nur eingeschränkter C++ Support (keine Namespaces und auch Templates nur sehr rudimentär) und nur für die Sprache selbst, die Standardlib wurde einfach mal zu 0(!)% unterstützt.

[Krishty]

Wow. Ich habe es eben zum ersten Mal seit Krishtygedenken geschafft, Windows 7 blauzuschirmen – indem ich in meiner Hauptschleife DispatchMessage() vergessen habe. Ich vermute, der Intel-Grafiktreiber mochte das nicht so.

Und die Tastensperre meines Handys lässt sich einfacher lösen, während jemand versucht, eine Bluetooth-Verbindung herzustellen.

Ist doch alles Müll.

Nachtrag: Nach dem Absturz sind alle meine Visual-C++-Einstellungen zurückgesetzt. Waaaaaaaaaah

[kaiserludi]

Ich habe seit Jahren keinen Blue Screen mehr gesehen, dafür verursacht OS X gerne mal Regenbogenscreens: Das ganze Screen ist ein plötzlich einziger riesiger Farbverlauf. Das mitten bei der Arbeit einfach mal der Screen einfriert, kommt auch häufiger vor. Spätestens seit Vista ist Windows meiner Erfahrung nach um Welten stabiler als OS X, wenn auch die aktuellen OS X (seit Leopard, ältere habe ich nie verwendet) immer noch weit stabiler sind als Windows 98.

[MoritzPGKatz]

Ich habe seit Jahren keinen Blue Screen mehr gesehen, dafür verursacht OS X gerne mal Regenbogenscreens: Das ganze Screen ist ein plötzlich einziger riesiger Farbverlauf. Das mitten bei der Arbeit einfach mal der Screen einfriert, kommt auch häufiger vor. Spätestens seit Vista ist Windows meiner Erfahrung nach um Welten stabiler als OS X, wenn auch die aktuellen OS X (seit Leopard, ältere habe ich nie verwendet) immer noch weit stabiler sind als Windows 98.

Das würde ich mal checken lassen... ich quäle mein MacBook täglich mit CPU- und RAM-intensiver Klangbearbeitung und Sampling - und dass es mir wirklich abschmiert, passiert äußerst selten. Vielleicht einmal im halben Jahr. Und schon gar nicht mit "Regenbogenscreen".

[Artificial Mind]

4. Habe auch mal für ein Mobile Linux (Meego) entwickelt. Daher kenn ich den QTCreator. Ich habe diese IDE schnell zu hassen gelernt: Verbuggt und schneckenlahm. Projektsettings ändern: 30Sekunden Wartezeit nach jedem Klick, bevor die IDE wieder reagiert hat. Nun änder da mal 4 Setting pro Konfiguration bei 8 Konfugurationen pro Projekt und 6 Projekten. Schön wars auch immer, wenn der Projektsettingsidalog sich horizontal auf 3 fache Screenauflösung vergrößert hat und man ihn nicht mehr kleiner bekam: Lustiges hin und herschieben. Dazu sind QTCreator-Projektdateien inkompatibel zu sauberer Versionsvewaltung, weil Projekteinstellungen und Sachen wie Timestamps des letzten Öffnens des Projektes in der selben Datei gespeichert werden.

Ah, du hast eine ewig alte Version vom QtCreator benutzt, richtig? Der war früher tatsächlich eine Katastrophe. Seit 2.x ist der mir noch nie richtig eingefroren (einzige Ausnahme: wenn man in GLSL Code den ternären ?-Operator benutzt friert das Programm zuverlässig ein. Das liegt aber eher am GLSL-Plugin und nicht an der IDE denke ich).

EDIT: Achja, und das hauseigene Projektformat nutzen wir auch nicht, sondern nur CMakeLists.txt, was sehr gut funktioniert.

[kaiserludi]

Hmm, die Version, die ich benutz habe, ist jetzt vielleicht 1, maximal 1,5 Jahre alt.

[Artificial Mind]

Ich arbeite erst seit einem halben Jahr wieder mit QtCreator, das könnte vielleicht echt der Punkt sein. Aber so wie du deine Anwendungsfälle schilderst, bist du mit einem VS mit VAX wahrscheinlich besser bedient. Bei mir an der Uni ist Linux nunmal Pflicht und bei uns ist auch alles in CMake-Projekten, deswegen gibt es nicht so viele Alternativen und von denen ist der QtCreator mMn die Beste.

[antisteo]

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.

Also bei VIM öffnet sich das Eingabefeld zum Suchen immer ziemlich flott. Vielleicht solltest du umsteigen ;)

[Thoran]

JAXB Namecollisions auflösen für w3c-erzeugte xsd-Dokumente ist nervig, vorallem wenn JAXB einem Fehlermeldungen mit geringem Informationsgehalt gibt und man selber neu in dem Thema ist. :x

[CodingCat]

Korrekt:

Nach 15 Frames mit CUDA-Interop (irgendwas, muss nicht mal ein CUDA-Kernel laufen, nur Resource Mappings):

Mit CUDA Interop (auf vollkommen anderen Ressourcen!) gehen ganz offensichtlich die D3D11 Atomics auf (bestimmten?) Ressourcen einfach kaputt.

Warum erst nach 15 Frames? Wie es aussieht werden Shader vom Treiber mit Verzögerung nachoptimiert. Die Heuristiken für die Nachoptimierung von Shadern sind alleine eine (vollkommen undokumentierte) Wissenschaft für sich. Wenn man Pech hat, kann einen schon das sämtliche Performance kosten:

Funny, discovering how drivers are delaying shader optim ~ if time(shader_non_opt) > time(delay_between_gpu_calls) then optimize_shader();
meaning that if a non optimized shader is taking 100ms and you call it every 200ms, It won't be optimized (optim shader is 6ms)
So It seems that shaders need to be warmup x times consecutively before actually using them in order for the driver to bother optimize them
It's on a GTX580, latest drivers. With compute shaders for bitonic sort, drivers compiles only after 4-6 sorts on 1M particles 1/2
If I put a CPU sleep of more than 100ms (with readback of results) between each sort, the shaders will never get optimized.
- https://twitter.com/xoofx

Meine Schlussfolgerung ist nun, dass CUDA Interop auch die Nachoptimierung von D3D11 Shadern beeinflusst, so dass am Ende vollkommener Müll dabei herauskommt. Workaround? Hab ich immer noch keinen.

Mit vergleichbarem Schwachsinn beschäftige ich mich nun schon seit Wochen, ohne in der eigentlichen Sache groß voranzukommen. Diese ganzen General-Purpose-DirectX-Erweiterungen erscheinen mir inzwischen mangels funktionierender Tools (kaputter Shader-Compiler, kaum Diagnosemöglichkeiten, kaputtes PIX, kaputtes nSight) und mangels funktionierender Treiber wie nutzloses Spielzeug, und ich bin froh, wenn ich diesen Mist für eine Weile nicht mehr sehen muss.

Neben den dicken Fehlern kommt übrigens jede Minor-Treiber-Version auch noch mit einer ganz eigenen Palette von "Eigenheiten".

[kaiserludi]

Wieso poppt eigentlich bei jedem zweiten Handyhersteller beim updaten eine Warnung auf, dass das Device unbrauchbar wird, wenn man es während dem Update vom Rechner trennt?
Haben die alle noch nie was davon gehört, dass es auch sowas wie Stromausfälle oder plötzliche Abstürze gibt?
Kann doch wohl nicht sein, dass man mit dem Gerät dann zum Hersteller muss, ums zu resetten.