Seite 90 von 252

Re: Jammer-Thread

Verfasst: 20.10.2012, 15:40
von dot
Was? Mach dir eben welche!?

Re: Jammer-Thread

Verfasst: 20.10.2012, 16:39
von CodingCat
Krishty hat geschrieben:Ich suche seit drei Stunden verzweifelt nach einer Möglichkeit, den Pfad meines Windows Driver Kits (7.1!) nicht in Projektdateien hard-coden zu müssen. WhyTF haben Windows SDK und DirectX SDK eigene Makros; das WDK 7.1 aber nicht?! Selbst, wenn ich die Umgebungsvariablen registriere, geht das nur für VS 2012, aber nicht für 2010.
WDK 8.0 hat wohl welche. Sollte 7.1 keine haben, einfach im Property-Manager-Reiter "Add New Project Property Sheet", Pfade setzen und irgendwo zentral abspeichern.

Re: Jammer-Thread

Verfasst: 20.10.2012, 17:12
von Krishty
Mist. Ich verteile meinen Quelltext und will ganz einfach, dass die Nutzer nirgends den Pfad eintragen müssen. Es soll sofort kompilieren – mit Windows- und DirectX SDK geht das ja auch.

Das 8.0-SDK ist nicht mehr Windows XP-kompatibel, oder?

Andererseits hat auch das 7.1-SDK keine XP-Version der hid.lib mehr, und es geht trotzdem unter XP. Mehr als die eine Datei brauche ich auch garnicht.

Re: Jammer-Thread

Verfasst: 20.10.2012, 19:10
von Krishty
Ich muss mich da ein wenig korrigieren: Irgendein Pfad wird da tatsächlich eingetragen; und die WDK-Bibliotheken werden auf Anhieb gefunden. Dummerweise geht das ausschließlich mit VS2012. Sobald ich das Platform Toolset auf 10.0 zurücksetze, ist das alles futtsch und er findet nix mehr.

Re: Jammer-Thread

Verfasst: 21.10.2012, 14:25
von CodingCat
Ich habe soeben all meine Ideale bezüglich einer einheitlichen funktionalen Notation über Bord geworfen und sogar meine neuen datenorientierten Entities mit einer objektorientierten Fassade versehen. Es ist an dieser Stelle wohl unsinnig, gegen den Strom (und vor allem gegen die IDE, die eigene Produktivität) zu schwimmen, während sich alle Welt im OOPa-Park amüsiert.

Re: Jammer-Thread

Verfasst: 21.10.2012, 14:37
von Krishty
Ach, Katze … wenn sich dieser Kampf nicht zu kämpfen lohnt, welcher dann?

Re: Jammer-Thread

Verfasst: 22.10.2012, 16:43
von glassbear
Argh, FTL ist einfach zu gut und so langsam hab ich den Dreh raus. Nach 50 Spielen bin ich zum ersten Mal beim Endgegner (auf "leicht") :mrgreen:

Re: Jammer-Thread

Verfasst: 22.10.2012, 18:01
von CodingCat
Wer wäre ich, wenn ich neben meinem Bildschirm nicht für jedes Problem die Template-Keule bereit liegen hätte. Stellt euch vor es ist 2012 und euer Compiler unterstützt noch immer keine Variadic Templates.

Code: Alles auswählen

enum EntityData
{
	registry,
	controllers,
	preciseTransformation,
	transformation,
	state,
	changedFlags
};

// Structure of arrays vector
typedef multi_vector<Registry, registry,
	multi_vector<EntityControllers, controllers,
	multi_vector<PreciseTransformation, preciseTransformation,
	multi_vector<Transformation, transformation,
	multi_vector<State, state,
	multi_vector<char, changedFlags> > > > > > entity_vector;
entity_vector entities;

// Insert entity
entities.push_back( Registry(handle), EntityControllers(eoc, eoc) );

// Access transformation
m.entities.get<transformation>()[InternalID].Position = position;

// Remove entity
entities.erase(internalID);
Nachtrag: Source natürlich wie immer hier.

Re: Jammer-Thread

Verfasst: 24.10.2012, 14:15
von CodingCat
Ihr habt euch sicher schon immer gefragt, was eigentlich passiert, wenn ihr simple Strukturen wie struct A { int i; }; in STL-Vektoren verpackt und dann fleißig reallokiert. Die Hoffnung: Der Compiler erkennt die triviale Kopieroperation und macht aus der Schleife zur Verschiebung von Objekten eine schöne Blockoperation, z.B. memmove. Pustekuchen! Die STL checkt intern, ob der Typ ein Skalar ist (offensichtlich nicht, A ist allenfalls eine Gruppe von Skalaren). Ist das nicht der Fall, wird fleißig Element für Element in einer Schleife kopiert, der Compiler stellt sich dumm.

Obwohl der neue Standard sogar triviale Kopierbar als offizielle Typeigenschaft einführt, macht die MSVC12 beigelegte STL keinen Gebrauch davon.

Nebenbei: Move Semantics hin oder her, dass bitweise Verschiebbarkeit auch im neuen Standard vollkommen ignoriert wird, ist mir unbegreiflich. Ich würde salopp schätzen, dass 99 % aller jemals in C++ definierten Klassen bitweise verschiebbar sind.

Re: Jammer-Thread

Verfasst: 24.10.2012, 15:29
von CodingCat
Aliasing ... ich habe gerade kurz darüber nachgedacht, wie man in einem vector die Funktion emplace_back und Konsorten implementieren würde. Schlussendlich bleibt einem wohl im Falle einer Reallokation nichts anderes übrig, als sämtliche übergebenen Konstruktorargumente einzeln auf Beinhaltung im alten Speicherbereich des vector zu prüfen und Adressen beinhalteter Argumente nach der Reallokation gegebenenfalls auf den neuen Speicherbereich umzubiegen.

Re: Jammer-Thread

Verfasst: 24.10.2012, 17:44
von Krishty
An dieser Stelle auch gleich eine Meckerei zu built-ins: Microsoft hat ja u.A. Intrinsics um festzustellen, ob eine Klasse trivially copyable ist. Man muss bedenken, dass diese Dinger wirklich nur das absolut Nötigste machen: Sie funktionieren nur mit Klassen. Mit nativen Datentypen, enums, unions, Zeigern, Methodenzeigern, und Arrays muss man selber zusehen, dass man diese gegebenenfalls als trivially copyable erkennt. Mein Text um POD als solche zu erkennen umfasst deswegen locker 150 Zeilen ekligster Templates.

Re: Jammer-Thread

Verfasst: 24.10.2012, 20:35
von Krishty
WTF

Kann mir jemand erklären, warum C++-Lambdas nicht auf statische Funktionen von Klassen zugreifen können sollten?

WTF WTF WTF



HAHAHAHAHA

Ein Compiler-Bug; was auch sonst

Ich habe drei Jahre gebraucht um einen vernünftigen Anwendungszweck für Lambdas zu finden

und dann sagt Visual C++: Nö is nich

Hab’ den Kaffee auf

    struct Exc {
        static __declspec(noreturn) void raise(char const *) {
            throw Exc();
        }
    };

    class Foo {
        struct BarBar { } & myBar;
    public:
        Foo()
            : myBar([] () -> BarBar & {
                Exc::raise("ffffuuuuu"); // error C2039: 'raise' : is not a member of 'Exc'
            } ())
        { }
    };


http://stackoverflow.com/questions/8113 ... e-paramete

Re: Jammer-Thread

Verfasst: 25.10.2012, 14:03
von eXile
Dann kannst du mir doch bestimmt auch beantworten, warum

Code: Alles auswählen

template <typename Dummy> // Comment out.
class MyClass
{
public:
    explicit MyClass(
    ) : myData([&]() -> char const * {
            return nullptr;
        }())
    {
        return;
    }

private:
    char const * myData;
};

int main(int argc, char * argv[])
{
    return 0;
}
in Visual Studio 2010 nicht kompiliert; wenn man die erste Zeile auskommentiert, dann kompiliert es.

Re: Jammer-Thread

Verfasst: 25.10.2012, 17:28
von Krishty
Wie gesagt – ich habe sie erst einmal benutzt. Ich meine aber was gelesen zu haben von wegen, dass Lambdas keine Templates sein dürften.

Re: Jammer-Thread

Verfasst: 25.10.2012, 18:07
von dot
Die Lambdas in VS 2010 sind noch ziemlich verbugged (iirc unter anderem ein Problem mit (unnamed?) Namespaces) und entsprechen auch nur dem damaligen Draft und nicht dem fertigen Standard (die Lambda -> Function Pointer Conversion fehlt beispielsweise). VS 2012 kompiliert es problemlos...

Re: Jammer-Thread

Verfasst: 25.10.2012, 18:16
von joggel
Aber sonst gehts hier noch....?
Häää.png
Häää.png (10.27 KiB) 2890 mal betrachtet
Wieso aktualisiert VS nicht die Makros? Das war nämlich der alte Inhalt der "BOOST"-Umgebungsvariable....

Re: Jammer-Thread

Verfasst: 25.10.2012, 18:49
von dot
Hast du VS auch neu gestartet?

Re: Jammer-Thread

Verfasst: 25.10.2012, 19:40
von joggel
Ja, sogar System-Neustart hat nichts gebracht...
Werd mal sehen ob es morgen geht.

Und wen nicht. Mir auch egal!!^^
Steige dort aus... also von arbeit.
Obwohl das eher in der Anti-Jammer-Thread kommen sollte...

Re: Jammer-Thread

Verfasst: 25.10.2012, 20:25
von dot
Ich könnt mir nur vorstellen, dass $(BOOST) irgendwo als Property definiert wird und die Env Var daher überschreibt. Inkludiert das Projekt z.B. irgendwelche Property Sheets!?

Re: Jammer-Thread

Verfasst: 25.10.2012, 20:30
von joggel
dot hat geschrieben:Ich könnt mir nur vorstellen, dass $(BOOST) irgendwo als Property definiert wird und die Env Var daher überschreibt. Inkludiert das Projekt z.B. irgendwelche Property Sheets!?
Nein. Nicht über ein Poperty(?).
"Property Sheets" auch nicht.
Das sind alles Umgebungsvariablen die über Win7 gesetzt sind.
Per Batch, mit "setx".

Re: Jammer-Thread

Verfasst: 25.10.2012, 20:32
von eXile
dot hat geschrieben:VS 2012 kompiliert es problemlos...
Hervorragend! Dann ist nur noch die Frage, wann Nvidia endlich aufwacht und Nsight auch für Visual Studio 2012 anbietet. Es ist fast 2013.

Re: Jammer-Thread

Verfasst: 25.10.2012, 20:37
von dot
Der nächste Release soll angeblich VS 2012 supporten. Ich hoffe er kommt spätestens morgen. Mein aktuelles Projekt ist mittlerweile nämlich grad im dem Status, wo NSight mir langsam wirklich abgeht...

Re: Jammer-Thread

Verfasst: 25.10.2012, 20:54
von Schrompf
Ich habe heute die Bedeutung des neuen Visual Studio 2012-Sicherheitsfeatures "Secure Development Lifecycle" kennengelernt. Es macht aus Deprecated-Warnungen Deprecated-Fehler. Danke, Microsoft.

Re: Jammer-Thread

Verfasst: 25.10.2012, 22:33
von Krishty
WTF Warum #includet <D3D11.h> die komplette D3D10.h?!

Und benutzt jemand die ganzen C++-Hilfsklassen, die da beigefügt wurden? Sind die zu empfehlen?

Re: Jammer-Thread

Verfasst: 25.10.2012, 22:36
von dot
Huch!? Was für C++ Hilfsklassen!? :D

Re: Jammer-Thread

Verfasst: 25.10.2012, 22:37
von CodingCat
Krishty hat geschrieben:WTF Warum #includet <D3D11.h> die komplette D3D10.h?!
Bestimmt wegen einiger weniger wiederverwendeter Konstanten. ;)
Krishty hat geschrieben:Und benutzt jemand die ganzen C++-Hilfsklassen, die da beigefügt wurden? Sind die zu empfehlen?
Ich wusste davon auch nichts, bis mich neulich eXile darauf hingewiesen hat. Drauf kamen wir weil eXile feststellte, dass die dort definierten StateDesc-Defaults nicht mit der Dokumentation und den tatsächlichen Direct3D-Defaults übereinstimmen. ;)

Re: Jammer-Thread

Verfasst: 26.10.2012, 06:56
von Krishty
Oh prächtig; dann weg damit. Dankääääääh

Re: Jammer-Thread

Verfasst: 26.10.2012, 12:23
von joggel
joggel hat geschrieben: [...]
Das sind alles Umgebungsvariablen die über Win7 gesetzt sind.
Per Batch, mit "setx".
Ich... ich möchte nicht darüber reden :(

[Nachtrag]
Also ich verstehe es selbst nicht so richtig.
Ich hatte wohl irgendwas falsch gemacht, als ich mein Benutzerkonto erstellt habe.
als ich über die CMD mal set aufgerufen habe, wurden mir dort alle Umgebungsvariablen angezeigt.
Deren Werte waren identisch mit denen die mir auch VS anzeigt. Bin ich aber über Systemsteuerung > .... Erweiterte Systemeinstellung > Umgebungsvariablen gegangen, wurden mir andere angezeigt. :?:
Wie gesagt, ich kann jetzt schlecht die Ursache rekonstruieren.
Aber ich habe mal dieses Benutzerkonto gelöscht und mir ein neues eingerichtet.
Es gab da anscheinend irgendwelche Namens-Konflikte... sorry das ich nicht genaueres sagen kann.

Re: Jammer-Thread

Verfasst: 27.10.2012, 08:49
von Krishty
typedef
enum D3D11_FEATURE {
    D3D11_FEATURE_THREADING = 0,
    D3D11_FEATURE_DOUBLES = ( D3D11_FEATURE_THREADING + 1 ) ,
    D3D11_FEATURE_FORMAT_SUPPORT = ( D3D11_FEATURE_DOUBLES + 1 ) ,
    D3D11_FEATURE_FORMAT_SUPPORT2 = ( D3D11_FEATURE_FORMAT_SUPPORT + 1 ) ,
    D3D11_FEATURE_D3D10_X_HARDWARE_OPTIONS = ( D3D11_FEATURE_FORMAT_SUPPORT2 + 1 )
} D3D11_FEATURE;


Warum, Microsoft

warum

Es ist ja nicht genug, dass ich die C-Deklarationen à la typedef struct XXX { } XXX; zu struct XXX { }; umschreiben muss; und dass ich so widerliche Deklarationsmatsche wie DECLARE_INTERFACE_(Foo, IUnknown) auseinanderpflücken darf – so ein Dreck mit enum muss auch noch sein. Vor allem kann ich es mir überhaupt nicht erklären: die Header sind automatisch erzeugt; da sitzt garkein Mensch dran und tippt das + 1 (hoffe ich zumindest). Explizit aufgelistete numerische Werte würde ich ja auch noch verstehen. Aber das …

Re: Jammer-Thread

Verfasst: 27.10.2012, 12:45
von CodingCat
Ich sitze hier gerade an Windows 8. Zunächst bin ich einfach nur glücklich, dass mein Windows 7 mit allen Dateien noch da ist. Nachdem ich erstmal ordentlich den Standard-Windows-8-Startbildschirm aufgeräumt habe, finde ich mich schon einigermaßen zurecht. Der erste Eindruck ist besser als befürchtet, insbesondere wird bei einem Dual-Screen-Setup offenbar sofort der Desktop gestartet. Der Startbildschirm belegt immer "nur" einen Bildschirm und der Wechsel ist weich und flink.

Im Metro-Teil finde ich mich hingegen noch gar nicht zurecht. Menüs finde ich dort nur zufällig, indem ich planlos zwischen Rechtsklick und Maus-an-Bildschrimränder-Bewegen alterniere. Insbesondere finde ich keine Möglichkeit, Metro-Applikationen, einmal gestartet, wieder zu beenden, ohne zuvor zum Startbildschirm oder einer anderen Anwendung zu wechseln, anschließend die Maus in die linke obere Ecke zu bewegen und dort in der erscheinenden Miniaturvorschau aller Anwendungen die gerade verlassene zu erkennen und per Rechtsklick -> Close zu schließen. Den Metro-Teil werde ich ohnehin ignorieren, dennoch war ich hier etwas überrascht.

Für den fehlenden Start-Button könnte ich Microsoft den Kopf abreißen. An Stelle des Start-Buttons findet sich nun ein sehr schmaler freier Streifen auf der Taskbar. Eine Vorschau des Startbildschirms taucht dort nur auf, wenn ich die Maus exakt in die Bildschirmecke bewege (schwierig, denn mein Hauptbildschirm ist der rechte).

Außerdem: Die neuen Fensterrahmen sind hässlich und unübersichtlich, egal wie ich sie färbe. Ich will die schönen transparenten aus Windows 7 wieder. Ich würde gerne einstellen, dass der Start-Bildschirm immer auf meinem Sekundärbildschirm landet. Ich würde gerne die Funktionalität einiger Bildschirmecken vertauschen.