Re: Anti-Jammer-Thread
Verfasst: 02.11.2012, 22:03
Ja genau. Da gibt's auch das schöne Diagramm:

Die deutsche Spieleentwickler-Community (seit 1999).
https://zfx.info/
Awww...yeah!111Part 6 is a special episode in which Stephan takes a look at the latest C++11 features that were just added to the Visual C++ compiler:
Variadic templates
Raw string literals
Explicit conversion operators
Default template arguments for function templates
Delegating constructors
Uniform initialization
Code: Alles auswählen
#ifndef INCLUDED_WIN32_WINDOW_CLASS
#define INCLUDED_WIN32_WINDOW_CLASS
#pragma once
#include "WindowHandle.h"
namespace Win32
{
template <class T, LRESULT (T::*WndProc)(HWND, UINT, WPARAM, LPARAM)>
class WindowClass
{
private:
ATOM cls;
static LRESULT CALLBACK BootstrapWndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
if (msg == WM_CREATE)
{
T* obj = static_cast<T*>(reinterpret_cast<CREATESTRUCT*>(lParam)->lpCreateParams);
SetWindowLongPtr(hWnd, GWLP_USERDATA, reinterpret_cast<LONG_PTR>(obj));
SetWindowLongPtr(hWnd, GWLP_WNDPROC, reinterpret_cast<LONG_PTR>(&WndProcThunk));
return (obj->*WndProc)(hWnd, msg, wParam, lParam);
}
return DefWindowProc(hWnd, msg, wParam, lParam);
}
static LRESULT CALLBACK WndProcThunk(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
T* obj = reinterpret_cast<T*>(GetWindowLongPtr(hWnd, GWLP_USERDATA));
return (obj->*WndProc)(hWnd, msg, wParam, lParam);
}
public:
WindowClass(LPCWSTR lpszClassName,
UINT style,
HICON hIcon,
HICON hIconSm,
HCURSOR hCursor,
HBRUSH hbrBackground = (HBRUSH)(COLOR_WINDOW + 1),
LPCTSTR lpszMenuName = nullptr)
{
WNDCLASSEXW wnd_cls;
wnd_cls.cbSize = sizeof(wnd_cls);
wnd_cls.style = style;
wnd_cls.lpfnWndProc = &BootstrapWndProc;
wnd_cls.cbClsExtra = 0;
wnd_cls.cbWndExtra = 0;
wnd_cls.hInstance = GetModuleHandleW(nullptr);
wnd_cls.hIcon = hIcon;
wnd_cls.hCursor = hCursor;
wnd_cls.hbrBackground = hbrBackground;
wnd_cls.lpszMenuName = lpszMenuName;
wnd_cls.lpszClassName = lpszClassName;
wnd_cls.hIconSm = hIconSm;
cls = RegisterClassExW(&wnd_cls);
}
~WindowClass()
{
UnregisterClassW(reinterpret_cast<LPCWSTR>(cls), GetModuleHandleW(nullptr));
}
WindowHandle createWindow(T& obj,
DWORD dwExStyle,
LPCWSTR lpWindowName,
DWORD dwStyle,
int X = CW_USEDEFAULT,
int Y = CW_USEDEFAULT,
int nWidth = CW_USEDEFAULT,
int nHeight = CW_USEDEFAULT,
HWND hWndParent = 0,
HMENU hMenu = 0)
{
return WindowHandle(CreateWindowExW(dwExStyle,
reinterpret_cast<LPCWSTR>(cls),
lpWindowName,
dwStyle,
X,
Y,
nWidth,
nHeight,
hWndParent,
hMenu,
GetModuleHandleW(nullptr),
&obj));
}
};
}
#endif // INCLUDED_WIN32_WINDOW_CLASS
Ganz einfach: NCCREATE ist nicht die erste sinnvolle Message, die man in der WndProc bekommt. Daher erhält man den Pointer auf die Klasse eventuell zu spät. Frag mich aber nicht welche Messages noch davor kommen, ich erinnere mich nicht mehr dran. Da ich damals diese (eine?) Message brauchte, war der TLS meine bevorzugte Wahl. Und noch ein Hinweis von mir: Passt bloß auf, dass in CALLBACKs keine Exceptions „nach Außen“ gelangen … Das passiert schneller als man denkt in C++ Code, vor allem in den benutzerdefinierten WndProcs.Krishty hat geschrieben:Warum benutzt unser FAQ-WndProc-in-Klasse-unterbring-Artikel eigentlich nicht den letzten Parameter von CreateWindowEx(), um den Zeiger in WM_NCCREATE zu setzen? Es ist doch so einfach.
Wofür genau die String Literale?Krishty hat geschrieben:Guter Punkt – du hast eine Fensterklasse für alle Fenster, die mit einem Kontext-Objekt kommen; ich bin spezialisierter und hatte schon eine bestimmte Fensterart vor Augen. Deins sieht auf jeden Fall eleganter aus (zumal es keine virtuellen Funktionen braucht); ich grüble nur, wie ich sauber String-Literale ins Template kriege …
Ja, das GetModuleHandle(nullptr) ist einzig und allein aus Faulheit drin. Auf jeden Fall danke für den Hinweis. Ich bin nur kein großer Fan der __ImageBase Variante, weil sie eigentlich auf mehr oder weniger undokumentiertem Verhalten basiert. GetModuleHandleEx() mit GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS bzw. einfach ein optionales HMODULE als Konstruktorparameter, wäre wohl die noch bessere Lösung.Krishty hat geschrieben:Dies und das: Ich setze den Zeiger schon in WM_NCCCREATE und lese ihn, wie erwähnt, nur für die Nachrichten, die ihn brauchen. Die WNDCLASSEX-Instanz ist bei mir static const; selbst ihr GetModuleHandleW(nullptr) kann man zur Übersetzungszeit durch reinterpret_cast<HMODULE>(__ImageBase) auflösen.
Natürlich hat deine Variante den Vorteil, dass wirklich von Anfang an alle Messages an die Methode weitergeleitet werden. Und ich muss zugeben, dass ich an TLS in dem Kontext noch gar nicht gedacht hab; aber TLS ist eine doch relativ knappe Ressource, die ich persönlich nur sehr ungern für sowas einsetzen würde...Biolunar hat geschrieben:Ganz einfach: NCCREATE ist nicht die erste sinnvolle Message, die man in der WndProc bekommt. Daher erhält man den Pointer auf die Klasse eventuell zu spät. Frag mich aber nicht welche Messages noch davor kommen, ich erinnere mich nicht mehr dran. Da ich damals diese (eine?) Message brauchte, war der TLS meine bevorzugte Wahl. Und noch ein Hinweis von mir: Passt bloß auf, dass in CALLBACKs keine Exceptions „nach Außen“ gelangen … Das passiert schneller als man denkt in C++ Code, vor allem in den benutzerdefinierten WndProcs.Krishty hat geschrieben:Warum benutzt unser FAQ-WndProc-in-Klasse-unterbring-Artikel eigentlich nicht den letzten Parameter von CreateWindowEx(), um den Zeiger in WM_NCCREATE zu setzen? Es ist doch so einfach.
Ich verwend WM_CREATE, weil es mir als das Logischste erschien. Früher hab ich überhaupt den Pointer erst nach dem CreateWindowEx() per SetWindowLongPtr() gesetzt, bis ich eines Tages eben auch mal auf die Idee kam, den lpParam von CreateWindowEx() zu benutzen. Das Problem ist, dass die genaue Abfolge an Messages, die CreateWindowEx() sendet, bevor es returned, nicht wirklich dokumentiert ist. Wobei ich mir auch überlegen werd, vielleicht WM_NCCREATE zu verwenden, nachdem das etwas früher kommt...Krishty hat geschrieben:Die allererste Nachricht ist WM_GETMINMAXINFO (damit das Fenster direkt mit der richtigen Größe erzeugt wird). Danach geht es direkt mit WM_NCCREATE weiter.
Wenn die Erzeugung eh im Kontext einer bestimmten Implementierung geschieht, kann man den auch dafür benutzen, das Fenster direkt mit der richtigen Größe zu erzeugen. Dann kann das erste WM_GETMINMAXINFO ruhig unbehandelt bzw. stanard-behandelt bleiben.
http://blogs.msdn.com/b/oldnewthing/archive/2004/10/11/240744.aspx hat geschrieben:But what good is the atom?
Not much, really.
Ja, so ist es wohl und macht auch Sinn, in der MSDN konnte ich aber bisher noch keine Dokumentation zu diesem Verhalten finden. Man beachte, dass nirgendwo steht, dass die Reihenfolge, in der die Nachrichten aufgelistet sind, auch tatsächlich die Reihenfolge ist, in der die Nachrichten gesendet werden. Die Dokumentation zu CreateWindow() listet sie sogar in anderer Reihenfolge als die von CreateWindowEx(), obwohl eigentlich beides die selbe Funktion ist (was aber natürlich auch nirgendwo wirklich dokumentiert ist)...Krishty hat geschrieben:WM_NCCREATE bedeutet, dass die Erzeugung des Fensterobjekts beginnt; nach WM_CREATE schließt sie ab. (Bei der Zerstörung ist es genau umgekehrt.)
Naja, ich verwend das ATOM, damit ich net den ganzen String kopieren muss. Natürlich wäre es noch besser, den String irgendwie statisch reinzubekommen, aber das müsste man wenn dann wohl als Template Argument und für String Literale funktoniert das nicht. Man könnte wohl mit Template Metaprogramming was machen, vielleicht einfach direkt, z.B. basierend auf der Adresse einer Methode, einen eindeutigen String generieren...das wars mir bisher aber noch nicht wert...Krishty hat geschrieben:Was dein ATOM angeht, scheint das nicht die allerbeste Lösung zu sein:http://blogs.msdn.com/b/oldnewthing/archive/2004/10/11/240744.aspx hat geschrieben:But what good is the atom?
Not much, really.
dot hat geschrieben:Ja, so ist es wohl und macht auch Sinn, in der MSDN konnte ich aber bisher noch keine Dokumentation zu diesem Verhalten finden. Man beachte, dass nirgendwo steht, dass die Reihenfolge, in der die Nachrichten aufgelistet sind, auch tatsächlich die Reihenfolge ist, in der die Nachrichten gesendet werden.
http://msdn.microsoft.com/de-de/library/windows/desktop/ms632635 hat geschrieben:[WM_NCCREATE is] Sent prior to the WM_CREATE message when a window is first created.
Wenn du jetzt noch irgendwo findest, dass Fenster erst nach ihrer Erzeugung zerstört werden, ist die Reihenfolge WM_NCCREATE; WM_CREATE; WM_DESTROY; WM_NCDESTROY offiziell dokumentiert. Oder was meinst du?http://msdn.microsoft.com/en-us/library/windows/desktop/ms632636 hat geschrieben:The DestroyWindow function sends the WM_NCDESTROY message to the window following the WM_DESTROY message.
Code: Alles auswählen
const char* static blub = "abc"; // OK
const char* blab = blub; // OK
const char* static blob = blab; // error
Code: Alles auswählen
void foo()
{
char name[] = "foo";
use(name); // OK
store(name); // error: object lifetime too short
store("foo"); // OK
}
const char *storedName;
void use(const char *name)
{
storedName = name; // error: object lifetime unspecified
}
void store(const char *extern name)
{
storedName = name; // OK
}
Um das zu verhindern, bräuchte man wohl relativ interessantes Verhalten, nämlich dass ein Pointer auf ein Objekt mit local automatic storage nur in einen Pointer der selbst local automatic storage duration hat gespeichert werden kann. Sowas wie cv qualifier, nur dass diese Qualifier mehr oder weniger über eine Ebene an Indirektion hinweg interagieren würden (der top-level local Qualifier ist für lokale Variablen implizit):CodingCat hat geschrieben:Richtig, sowas bräuchte man nicht nur hier. Ich bin auch schon am überlegen, wie man permanente Zeiger und temporäre Zeiger allgemeiner formalisieren könnte. Sehr häufig gibt man Zeiger (Referenzen) auf Stack-Objekte weiter, die mit der Zerstörung des jeweiligen Stack-Objekts ungültig werden. Das ist i.d.R. auch überhaupt kein Problem, weil zuvor alle Unteraufrufe wieder vom Stack verschwinden.
Code: Alles auswählen
local int x; // OK
local int* local px = &x; // OK
int** blub = new int*;
*blub = &px; // error
Ganz genau. Und ganz genau, deshalb liegt dieses Proposal bei dem anderen, das ebenfalls 99.99999% aller vorhandenen C++ Programme zerstören würde; auf Halde.dot hat geschrieben:Um das zu verhindern, bräuchte man wohl relativ interessantes Verhalten, nämlich dass ein Pointer auf ein Objekt mit local automatic storage nur in einen Pointer der selbst local automatic storage duration hat gespeichert werden kann. Sowas wie cv qualifier, nur dass diese Qualifier mehr oder weniger über eine Ebenen hinweg interagieren würden (der top-level local Qualifier ist für lokale Variablen implizit):
[...]
Das Problem ist wohl nur, dass das so ziemlich 99.99999% aller vorhandenen C++ Programme breaken würde...
Code: Alles auswählen
void f()
{
int x;
int* px = &x; // px is implicitly declared int auto* px, deduced to int local* px
int** blub = new int*; // blub is implicitly declared int * auto * blub, deduced to int * dynamic * blub
*blub = px; // error: px is of type int local*, *blub is of type int dynamic*
}
Code: Alles auswählen
void f()
{
static int x;
int* x = new int; // OK, new int returns int dynamic*, can be converted to int*
int* y = &x; // OK, &x is int static*, can be converted to int*
int a;
int* z = &a; // error, can't convert int local* to int*
}
Code: Alles auswählen
struct A
{
int *p;
};
A g; // g global => p hat Typ int *extern
void foo()
{
int i;
A a; // a lokal => p hat Typ int *local
a.p = &i; // OK
foo(a); // OK
g.p = &i; // error
foo(g); // OK
A &r = a; // Referenz lokal
r.p = &i; // OK
foo(r); // OK
extern A b; // b extern => p hat Typ int *extern
b.p = &i; // error
foo(b); // OK
}
void bar(A &a)
{
int j;
a.p = &j; // error: _Parameter_-Referenz auf a NICHT mehr lokal => p hat Typ int *extern?!
int *p = a.p; // error: p hat Typ int *local?!
// a.p hat einen Zwischentyp, nämlich Referenz auf externes int*local, also int *extern local
}
Code: Alles auswählen
int* g;
void f()
{
int x;
int** y = new int*; // OK, int* auto* can be assigned int* dynamic*
int* px = &x; // OK, int auto* can be assigned int local*
*y = &x; // error, int* can't be assigned int local*
*y = px; // error, int* can't be assigned int auto*
px = *y; // OK, int auto* can be assigned int*
g = px; // error, int* can't be assigned int auto*
px = g; // OK, int auto* can be assigned int*
}
// second level auto is implicitly declared on local variables, top level auto/storage class qualifier is ignored just like with function signatures
Code: Alles auswählen
int* g;
int** h = &g; // OK, int* static* can be converted to int**
void f()
{
int x;
int* px = &x; // OK, no conversion necessary
int** y = new int*; // OK, int** can be converted to int* local*
*y = &x; // error, int local* can't be converted to int*
*y = px; // error, int local* can't be converted to int*
px = *y; // OK, int* can be converted to int local*
g = px; // error, int local* can't be converted to int static*
px = g; // OK, int static* can be converted to int local*
*y = g; // OK, no conversion necessary
y = &g; // OK, int* static* can be converted to int* local*
g = *y; // OK, int* can be converted to int static*
}