Anti-Jammer-Thread
- Schrompf
- Moderator
- Beiträge: 4884
- Registriert: 25.02.2009, 23:44
- Benutzertext: Lernt nur selten dazu
- Echter Name: Thomas Ziegenhagen
- Wohnort: Dresden
- Kontaktdaten:
Re: Anti-Jammer-Thread
Soeben bemerkt: SevenZip ist LGPL. Das war erstmal ein gemischtes Erlebnis, weil ich damit diese prächtige Kompression im eigenen Code zumindest kostenlos nutzen, aber doch sehr mühsam integrieren muss. Aber einen Klick später stellte sich heraus: LGPL gilt nur für die 7z-Anwendung! Das SDK selbst und damit die Lib, um im eigenen Code komprimieren und dekomprimieren zu können, ist Public Domain! Große Freude! Einfach die Source Files mit ins Projekt packen und durchkompilieren - fertig.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
-
- Establishment
- Beiträge: 201
- Registriert: 07.07.2010, 13:00
- Kontaktdaten:
Re: Anti-Jammer-Thread
Wieso musst du LGPL so aufwändig integrieren? Dynamisch gelinkte DLL tut's doch...
Imaging-Software und bald auch Middleware: http://fd-imaging.com
- Schrompf
- Moderator
- Beiträge: 4884
- Registriert: 25.02.2009, 23:44
- Benutzertext: Lernt nur selten dazu
- Echter Name: Thomas Ziegenhagen
- Wohnort: Dresden
- Kontaktdaten:
Re: Anti-Jammer-Thread
Korrekt. "Dynamisch linken" als erstes Ärgernis. Weil der Code ja so viel besser wird, wenn man ihn aus einer extra Datei zieht und durch ein Rudel Funktionszeiger jagt, anstatt ihn einfach mit in der Exe abzulegen.
Und als zweites Ärgernis das Name Mangeling und die Runtime-Spaße, divergierende Heaps und wasweißichnoch, dass bei C++-Code in DLLs für richtig Freude sorgt. Am Ende muss man die Lib dann eh genau mit dem Compiler und den Settings bauen, die man auch im Hauptprogramm nutzt, nur erzwingt die Lizenz am Ende das dynamische Linken. Tolle Wurst, und ein prima Beispiel dafür, was für Schaden diese ganze verbohrte Ideologie anrichten kann.
Da freue ich mich doch über Leute, die Open Source wirklich ernst nehmen. Und diese Freude habe ich hier zum Ausdruck gebracht.
Und als zweites Ärgernis das Name Mangeling und die Runtime-Spaße, divergierende Heaps und wasweißichnoch, dass bei C++-Code in DLLs für richtig Freude sorgt. Am Ende muss man die Lib dann eh genau mit dem Compiler und den Settings bauen, die man auch im Hauptprogramm nutzt, nur erzwingt die Lizenz am Ende das dynamische Linken. Tolle Wurst, und ein prima Beispiel dafür, was für Schaden diese ganze verbohrte Ideologie anrichten kann.
Da freue ich mich doch über Leute, die Open Source wirklich ernst nehmen. Und diese Freude habe ich hier zum Ausdruck gebracht.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
- Krishty
- Establishment
- Beiträge: 8268
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Anti-Jammer-Thread
Ja; Public Domain ist das Nonplusultra. Allerdings habe ich gehört, dass der Quelltext locker dem Obfuscated C Contest entsprungen sein könnte; also wehe, du willst was ändern.
(Persönlich hatte ich vor zwei Jahren die PPMd-Implementierung unter die Lupe genommen und nach einer Woche schlicht das Projekt aufgegeben. Das hört ihr von der kranken Seele, die seit Wochen Direct3D- und Windows-Header auseinanderpflückt.)
(Persönlich hatte ich vor zwei Jahren die PPMd-Implementierung unter die Lupe genommen und nach einer Woche schlicht das Projekt aufgegeben. Das hört ihr von der kranken Seele, die seit Wochen Direct3D- und Windows-Header auseinanderpflückt.)
-
- Establishment
- Beiträge: 201
- Registriert: 07.07.2010, 13:00
- Kontaktdaten:
Re: Anti-Jammer-Thread
Ich habe bei meinen Projekten kaum Probleme mit der Lizenz einzelner Libraries. Beispielsweise ImageMagick oder GraphicsMagick binden wir dynamisch, ohne manuell zu Laufzeit Funktionspointer zurecht zu biegen... LGPL halte ich für noch für eine sehr entwicklerfreundliche Lizenz. Nicht im Vergleich zu GPL...
Imaging-Software und bald auch Middleware: http://fd-imaging.com
- Krishty
- Establishment
- Beiträge: 8268
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Anti-Jammer-Thread
Die Funktionszeiger, die Schrompf meint, legt der Compiler automatisch für dich an („biegt sie zurecht“).
Ich persönlich lehne sowas aus Aversion gegen Indirektionen und sinnlose Verschwenderei kategorisch ab. Aber ich bin auch die kaputte Seele, die den kompletten Adressraum ihrer Programme auf einzelne unnütze Allokationen analysiert und von einem Programm erwartet, dass es nach 0,1 s Ladezeit fertig auf dem Bildschirm erschienen ist.
Ich persönlich lehne sowas aus Aversion gegen Indirektionen und sinnlose Verschwenderei kategorisch ab. Aber ich bin auch die kaputte Seele, die den kompletten Adressraum ihrer Programme auf einzelne unnütze Allokationen analysiert und von einem Programm erwartet, dass es nach 0,1 s Ladezeit fertig auf dem Bildschirm erschienen ist.
-
- Establishment
- Beiträge: 467
- Registriert: 18.04.2002, 15:31
Re: Anti-Jammer-Thread
Gerade
durch
ersetzt.
Ergebnis:
60% Performancegewinn für die Zeile und 17%(!) für den gesamten Worflow von Hashtable.put() über C++ to C conversion, serialization, deserialization, conversion back.
Code: Alles auswählen
for(; i<23 && s > 16777216u >> (23-i); ++i);
Code: Alles auswählen
i=s>8?s>16?s>32?s>64?s>128?s>256?s>512?s>1024?s>2048?s>4096?s>8192?s>16384?s>32768?s>65536?s>131072?s>262144?s>524288?s>1048576?s>2097152?s>4194304?s>8388608?s>16777216?22:21:20:19:18:17:16:15:14:13:12:11:10:9:8:7:6:5:4:3:2:1:0;
Ergebnis:
60% Performancegewinn für die Zeile und 17%(!) für den gesamten Worflow von Hashtable.put() über C++ to C conversion, serialization, deserialization, conversion back.
"Mir ist auch klar, dass der Tag, an dem ZFX und Developia zusammengehen werden der selbe Tag sein wird, an dem DirectGL rauskommt."
DirectGL, endlich ist es da :)
"According to the C++ standard, it's "undefined". That's a technical term that means, in theory, anything can happen: the program can crash, or keep running but generate garbage results, or send Bjarne Stroustrup an e-mail saying how ugly you are and how funny your mother dresses you." :shock:[/size]
DirectGL, endlich ist es da :)
"According to the C++ standard, it's "undefined". That's a technical term that means, in theory, anything can happen: the program can crash, or keep running but generate garbage results, or send Bjarne Stroustrup an e-mail saying how ugly you are and how funny your mother dresses you." :shock:[/size]
Re: Anti-Jammer-Thread
Wenn du hier schon so einen Krishty pullst, magst du mir bitte noch mitteilen, welche Hashfunktion du eigentlich benutzt. ;) Ich benutze MurmurHash3_x86_32, welches eine exzellente Performance und Hash-Distribution besitzt (die x86_32-Version gibt dir einen uint32_t zurück; x64 ergäbe da keinen Sinn).kaiserludi hat geschrieben:Hashtable
-
- Establishment
- Beiträge: 467
- Registriert: 18.04.2002, 15:31
Re: Anti-Jammer-Thread
Gar keine :mrgreen:
Die Klasse hat ein den Hashtables in Java und C# nachempfundenes Interface, aber intern werden derzeit einfach 2 Vector<Object> für Keys und Values verwendet. Die Anzahl der Einträge ist paktisch immer sehr übersichtlich, so dass das über die keys rüber iterieren nicht unfassbar teuer ist. Eventuell schaue ich mir den Punkt aber demnächst auch mal an in punkto Optimierungsbedarf.
Die Klasse hat ein den Hashtables in Java und C# nachempfundenes Interface, aber intern werden derzeit einfach 2 Vector<Object> für Keys und Values verwendet. Die Anzahl der Einträge ist paktisch immer sehr übersichtlich, so dass das über die keys rüber iterieren nicht unfassbar teuer ist. Eventuell schaue ich mir den Punkt aber demnächst auch mal an in punkto Optimierungsbedarf.
Zuletzt geändert von kaiserludi am 31.10.2012, 21:42, insgesamt 1-mal geändert.
"Mir ist auch klar, dass der Tag, an dem ZFX und Developia zusammengehen werden der selbe Tag sein wird, an dem DirectGL rauskommt."
DirectGL, endlich ist es da :)
"According to the C++ standard, it's "undefined". That's a technical term that means, in theory, anything can happen: the program can crash, or keep running but generate garbage results, or send Bjarne Stroustrup an e-mail saying how ugly you are and how funny your mother dresses you." :shock:[/size]
DirectGL, endlich ist es da :)
"According to the C++ standard, it's "undefined". That's a technical term that means, in theory, anything can happen: the program can crash, or keep running but generate garbage results, or send Bjarne Stroustrup an e-mail saying how ugly you are and how funny your mother dresses you." :shock:[/size]
- dot
- Establishment
- Beiträge: 1734
- Registriert: 06.03.2004, 18:10
- Echter Name: Michael Kenzel
- Kontaktdaten:
Re: Anti-Jammer-Thread
Wenn du in C++ eine Hashtable brauchst: http://en.cppreference.com/w/cpp/contai ... rdered_map ;)
-
- Establishment
- Beiträge: 467
- Registriert: 18.04.2002, 15:31
Re: Anti-Jammer-Thread
Und wenn ich eine brauche, die ohne C++ 11 und ohne C++ stdlib auskommen muss? ;)dot hat geschrieben:Wenn du in C++ eine Hashtable brauchst: http://en.cppreference.com/w/cpp/contai ... rdered_map ;)
"Mir ist auch klar, dass der Tag, an dem ZFX und Developia zusammengehen werden der selbe Tag sein wird, an dem DirectGL rauskommt."
DirectGL, endlich ist es da :)
"According to the C++ standard, it's "undefined". That's a technical term that means, in theory, anything can happen: the program can crash, or keep running but generate garbage results, or send Bjarne Stroustrup an e-mail saying how ugly you are and how funny your mother dresses you." :shock:[/size]
DirectGL, endlich ist es da :)
"According to the C++ standard, it's "undefined". That's a technical term that means, in theory, anything can happen: the program can crash, or keep running but generate garbage results, or send Bjarne Stroustrup an e-mail saying how ugly you are and how funny your mother dresses you." :shock:[/size]
- dot
- Establishment
- Beiträge: 1734
- Registriert: 06.03.2004, 18:10
- Echter Name: Michael Kenzel
- Kontaktdaten:
Re: Anti-Jammer-Thread
Wenn du Glück hast, hat dein Compiler eine in std::tr1:: ;)
- CodingCat
- Establishment
- Beiträge: 1857
- Registriert: 02.03.2009, 21:25
- Wohnort: Student @ KIT
- Kontaktdaten:
Re: Anti-Jammer-Thread
Visual Studio 2012 bekommt mit Update 1:
Mehr Updates nächstes Jahr. Das ist doch mal eine großartige Überraschung.
- Variadic Templates,
- Initializer Lists,
- Uniform Initializiation,
- Delegating Constructors,
- Function Template Default Arguments,
- Raw String Literals und
- Explicit Conversion Operators.
Mehr Updates nächstes Jahr. Das ist doch mal eine großartige Überraschung.
Zuletzt geändert von CodingCat am 02.11.2012, 21:27, insgesamt 1-mal geändert.
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
Re: Anti-Jammer-Thread
Oh wow. Bester Tag seit langem.
- CodingCat
- Establishment
- Beiträge: 1857
- Registriert: 02.03.2009, 21:25
- Wohnort: Student @ KIT
- Kontaktdaten:
Re: Anti-Jammer-Thread
C++ Roadmap bis 2017 nach Herb Sutter:
isocpp.org soll wohl die neue offizielle Sammelstelle für aktuelle Informationen zu C++ und der weiteren Standardisierung werden.
- File System (Tech Report) Ende 2013
(MSVC12 Update 1 wird in etwa Boost File System V2 enthalten) - Network (Tech Reports) verteilt 2013 bis 2015
- Run-time-sized Local Arrays ("Stack Arrays")
- Static If
- Generic Lambdas
- Function Return Type Deduction
- Concurrent Queues
- Reader-writer Locks
- std::literals
isocpp.org soll wohl die neue offizielle Sammelstelle für aktuelle Informationen zu C++ und der weiteren Standardisierung werden.
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
Re: Anti-Jammer-Thread
Ja genau. Da gibt's auch das schöne Diagramm:
- dot
- Establishment
- Beiträge: 1734
- Registriert: 06.03.2004, 18:10
- Echter Name: Michael Kenzel
- Kontaktdaten:
Re: Anti-Jammer-Thread
omg omg omg...kann es wirklich sein? http://www.microsoft.com/en-us/download ... x?id=35515
-
- Establishment
- Beiträge: 201
- Registriert: 07.07.2010, 13:00
- Kontaktdaten:
Re: Anti-Jammer-Thread
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
Imaging-Software und bald auch Middleware: http://fd-imaging.com
- Schrompf
- Moderator
- Beiträge: 4884
- Registriert: 25.02.2009, 23:44
- Benutzertext: Lernt nur selten dazu
- Echter Name: Thomas Ziegenhagen
- Wohnort: Dresden
- Kontaktdaten:
Re: Anti-Jammer-Thread
Uuuuuunglaublich! Mensch, das sind doch mal gute Neuigkeiten zum Samstag!
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
- Krishty
- Establishment
- Beiträge: 8268
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Anti-Jammer-Thread
http://msdn.microsoft.com/en-us/library/9598wk25.aspx
Wieder 200 B gespart.
Wieder 200 B gespart.
- Krishty
- Establishment
- Beiträge: 8268
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Anti-Jammer-Thread
Nach zehn Jahren habe ich Fensterklassen halbwegs verstanden und eine minimale C++-Klasse geschrieben, die es tatsächlich schafft, ein stinknormales Anzeigefenster objektorientiert zu kapseln. Ich Superheld ich.
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.
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.
- dot
- Establishment
- Beiträge: 1734
- Registriert: 06.03.2004, 18:10
- Echter Name: Michael Kenzel
- Kontaktdaten:
Re: Anti-Jammer-Thread
Hehe, meine Standardlösung dafür:
Ich bin aber nicht ganz zufrieden damit, auch wenn ich schon lang nimmer dran gebastelt hab. Im Idealfall würde der Object Pointer nur bei den Messages ausgelesen, deren Behandlung ihn auch erfordert...
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
- Krishty
- Establishment
- Beiträge: 8268
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Anti-Jammer-Thread
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 …
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.
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.
Re: Anti-Jammer-Thread
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.
- Krishty
- Establishment
- Beiträge: 8268
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Anti-Jammer-Thread
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.
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.
- dot
- Establishment
- Beiträge: 1734
- Registriert: 06.03.2004, 18:10
- Echter Name: Michael Kenzel
- Kontaktdaten:
Re: Anti-Jammer-Thread
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.
Bezüglich Exceptions: http://www.altdevblogaday.com/2012/07/0 ... esnt-work/ ;)
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.
- Krishty
- Establishment
- Beiträge: 8268
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Anti-Jammer-Thread
WM_NCCREATE bedeutet, dass die Erzeugung des Fensterobjekts beginnt; nach WM_CREATE schließt sie ab. (Bei der Zerstörung ist es genau umgekehrt.)
Welche Nachrichten genau eintreffen ist nicht dokumentiert (das Fenster wird ja je nach Darstellungsart, Sichtbarkeit usw. noch aktiviert, in der Größe angepasst usw); für die vier (NC)CREATE/DESTROY-Nachrichten ist die Reihenfolge aber auf der MSDN definiert.
Ups, die Hälfte vergessen: Den String möchte ich als statischen Parameter reinkriegen, damit die Klassenbeschreibung beim Kompilieren als Read-only-Data angelegt wird (genau wie __ImageBase).
Was dein ATOM angeht, scheint das nicht die allerbeste Lösung zu sein:
Welche Nachrichten genau eintreffen ist nicht dokumentiert (das Fenster wird ja je nach Darstellungsart, Sichtbarkeit usw. noch aktiviert, in der Größe angepasst usw); für die vier (NC)CREATE/DESTROY-Nachrichten ist die Reihenfolge aber auf der MSDN definiert.
Ups, die Hälfte vergessen: Den String möchte ich als statischen Parameter reinkriegen, damit die Klassenbeschreibung beim Kompilieren als Read-only-Data angelegt wird (genau wie __ImageBase).
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
- Establishment
- Beiträge: 1734
- Registriert: 06.03.2004, 18:10
- Echter Name: Michael Kenzel
- Kontaktdaten:
Re: Anti-Jammer-Thread
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.
Aber gut, ich dachte mir schon fast, dass du mit den String Literalen das meintest und da hast du natürlich recht, das wäre eine noch bessere Lösung...
- Krishty
- Establishment
- Beiträge: 8268
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Anti-Jammer-Thread
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.
- dot
- Establishment
- Beiträge: 1734
- Registriert: 06.03.2004, 18:10
- Echter Name: Michael Kenzel
- Kontaktdaten:
Re: Anti-Jammer-Thread
Ok, damit ist es wohl ausreichend definiert :)