Anti-Jammer-Thread

[Schrompf]

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.

[j.klugmann]

Wieso musst du LGPL so aufwändig integrieren? Dynamisch gelinkte DLL tut's doch...

[Schrompf]

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.

[Krishty]

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.)

[j.klugmann]

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...

[Krishty]

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.

[kaiserludi]

Gerade

Code: Alles auswählen

for(; i<23 && s > 16777216u >> (23-i); ++i);

durch

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;

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.

[eXile]

Hashtable

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]

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.

[dot]

Wenn du in C++ eine Hashtable brauchst: http://en.cppreference.com/w/cpp/contai ... rdered_map ;)

[kaiserludi]

Wenn du in C++ eine Hashtable brauchst: http://en.cppreference.com/w/cpp/contai ... rdered_map ;)

Und wenn ich eine brauche, die ohne C++ 11 und ohne C++ stdlib auskommen muss? ;)

[dot]

Wenn du Glück hast, hat dein Compiler eine in std::tr1:: ;)

[CodingCat]

Visual Studio 2012 bekommt mit Update 1:

• Variadic Templates,
• Initializer Lists,
• Uniform Initializiation,
• Delegating Constructors,
• Function Template Default Arguments,
• Raw String Literals und
• Explicit Conversion Operators.

Community Tech Preview mit all diesen Features ab sofort: http://www.microsoft.com/en-us/download ... x?id=35515 (noch ohne aktualisierte STL- und IntelliSense)

Mehr Updates nächstes Jahr. Das ist doch mal eine großartige Überraschung.

[eXile]

Oh wow. Bester Tag seit langem.

[CodingCat]

C++ Roadmap bis 2017 nach Herb Sutter:

• 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

Ein (kleiner) Teil davon möglicherweise 2014, der Rest 2017.

isocpp.org soll wohl die neue offizielle Sammelstelle für aktuelle Informationen zu C++ und der weiteren Standardisierung werden.

[eXile]

Ja genau. Da gibt's auch das schöne Diagramm:

[dot]

omg omg omg...kann es wirklich sein? http://www.microsoft.com/en-us/download ... x?id=35515

[j.klugmann]

Part 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

Awww...yeah!111

[Schrompf]

Uuuuuunglaublich! Mensch, das sind doch mal gute Neuigkeiten zum Samstag!

[Krishty]

http://msdn.microsoft.com/en-us/library/9598wk25.aspx
Wieder 200 B gespart.

[Krishty]

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.

[dot]

Hehe, meine Standardlösung dafür:

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

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...

[Krishty]

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.

[Biolunar]

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.

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]

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.

[dot]

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 …

Wofür genau die String Literale?

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.

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.

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.

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.

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...

Bezüglich Exceptions: http://www.altdevblogaday.com/2012/07/0 ... esnt-work/ ;)

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.

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]

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:

But what good is the atom?
Not much, really.

[dot]

WM_NCCREATE bedeutet, dass die Erzeugung des Fensterobjekts beginnt; nach WM_CREATE schließt sie ab. (Bei der Zerstörung ist es genau umgekehrt.)

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)...

Was dein ATOM angeht, scheint das nicht die allerbeste Lösung zu sein:

But what good is the atom?
Not much, really.

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...

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]

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.

[WM_NCCREATE is] Sent prior to the WM_CREATE message when a window is first created.

The DestroyWindow function sends the WM_NCDESTROY message to the window following the WM_DESTROY message.

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?

[dot]

Ok, damit ist es wohl ausreichend definiert :)