ZFX + Developia

eXile hat geschrieben: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.

MSDN hat geschrieben: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.

kaiserludi hat geschrieben: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.

kaiserludi hat geschrieben: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.

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);
};

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);
};

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 hat geschrieben: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.

kaiserludi hat geschrieben:Deine Varianten sehen allerdings auch interessant aus.

kaiserludi hat geschrieben: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.

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

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

Artificial Mind hat geschrieben: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 hat geschrieben:

Artificial Mind hat geschrieben: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.

kaiserludi hat geschrieben: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.

kaiserludi hat geschrieben: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.

Krishty hat geschrieben: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.

Alexandre Mutel hat geschrieben: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