Jammer-Thread

[Krishty]

Man sollte auch seine Backups backuppen. Ich habe letztes Wochenende gemerkt, dass meine vor 15 Jahren gebrannten CDs unlesbar geworden sind.

[Spiele Programmierer]

CDs sind zum Backup größerer Mengen auch ungeeignet.

[Krishty]

Unter Windows 98 war das ein Bisschen anders :-)

Nicht zuletzt habe ich auch meine PlayStation-Spiele gebrannt damit die Originale nicht so zerkratzen. Die Originale gehen aber zum Glück noch (wer weiß, wie lange – Abbilder sind gezogen).

[Schrompf]

Hallo, Freiberufler. Soeben insgesamt 11k Euro Steuern an das Finanzamt überwiesen. War eine Kombination aller möglichen Zahlungen, und es gibt sicher ne Menge Leute, die viel mehr Steuern zahlen. Aber eine solche Summe abwandern zu sehen, TUT WEH. Und man sollte sich als Freiberufler halt immer gewahr sein, dass ein Gutteil des Geldes, was man so von Kunden überwiesen bekommt, einem gar nicht gehört. Man verwahrt es nur für das Finanzamt oder die Krankenkasse, bis der Fälligkeitstermin ran ist.

[Alexander Kornrumpf]

Mach dir nichts raus. Ab dem zweiten Jahr wollen sie das Quartalsweise als Vorauszahlung haben, da ist es dann nicht soviel auf einmal :twisted:

Steuern heißt ja immer auch, dass du Geld verdient hast. Also zumindest sag ich mir das wenn ich die Überweisung zur Bank trage.

[Krishty]

Wenn du von Steuern leben willst statt sie zu bezahlen, entwickel halt Kampfdrohnen, Bundestrojaner, oder Hartz-IV-Kontrollsysteme!

[Krishty]

Wo wir gerade beim Thema waren: Den Bundestrojaner gibt’s jetzt hier.

WikiLeaks conservatively estimates FinFisher's revenue from these sales to amount to around €50,000,000.

[Krishty]

Das Wochenrätsel: Welche Maschinenbefehle erzeugt Visual C++ 2013 für diese Zeile?

  auto tickDuration = 1.0 / double(Windows::QueryPerformanceFrequency());

Hinweis: Es hat was hiermit zu tun …

*Trommelwirbel*

Richtig: EINEN SPRUNG!

  lea      rcx,[rsp+30h]
  call     qword ptr [__imp_QueryPerformanceFrequency]
  mov      rax,qword ptr [rsp+30h]
  xorps    xmm1,xmm1
  cvtsi2sd xmm1,rax
  test     rax,rax
  jns      label_0
  addsd    xmm1,mmword ptr [__real@43f0000000000000]
label_0:
  movsd    xmm0,mmword ptr [__real@3ff0000000000000]
  divsd    xmm0,xmm1
  movsd    mmword ptr [tickDuration],xmm0

cvtsi2sd konvertiert eine 64-Bit-Integer zu einer double – aber signed. Falls der Wert unsigned ist und das obere Bit gesetzt ist, muss 2^64 addiert werden. Ich war so irrational, anzunehmen, dass ich für Timer-Frequenzen keine negativen Zahlen bräuchte :roll:

Früher war das eine häufige Leistungseinbuße (daher die Regel: Vor der Konvertierung unsigned int -> float immer zu signed int konvertieren, falls möglich!); mit x64 geriet das in den Hintergrund (weil unsigned __int32 einfach als signed __int64 reinterpretiert wird, was kostenlos ist, und dann eine 64-Bit-Konvertierung durchgeführt wird). Aber bei unsigned __int64 beißt es einen natürlich wieder in den Hintern. Also Vorzeichen hinzufügen:

  lea      rcx,[rsp+30h]
  call     qword ptr [__imp_QueryPerformanceFrequency]
  movsd    xmm1,mmword ptr [__real@3ff0000000000000]
  xorps    xmm0,xmm0
  cvtsi2sd xmm0,qword ptr [rsp+30h]
  divsd    xmm1,xmm0
  movsd    mmword ptr [tickDuration],xmm1
  add      rsp,28h

[Krishty]

  myProg.exe!print:
  call OutputDebugStringW

*F11*

  myProg.exe!OutputDebugStringW:
  jmp qword ptr [__imp_OutputDebugStringW]

*F11*

  kernel32dll!OutputDebugStringWStub:
  jmp OutputDebugStringW

*F11*

  kernel32dll!OutputDebugStringW:
  jmp qword ptr [__imp_OutputDebugStringW]

*F11*

  KernelBase.dll!OutputDebugStringW:
  *endlich richtiger Code*
  call OutputDebugStringA

When in doubt, add another layer of indirection

[kimmi]

Wie mich diese UNicode-Hüllen in VS nerven, passt hier leider auf keine Seite :).

Gruß Kimmi

[dot]

Wtf, OutputDebugStringW called OutputDebugStringA :o

Ist das eine 32-Bit Anwendung auf einem 64-Bit System? Sieht nämlich irgendwie danach aus... ;)

[kimmi]

Meistens hängt das von deiner Unicode-Einstellung ab. Der eine ruft den anderen, wenn ...
Das ist einer der Geheimnisse, warum Word seit Anbeginn der Zeit genau so langsam ist wie die erste Variante auf einem 386'er. So ähnlich läuft das mit mittleren management in Konzernen bzw. größeren Firmen. Da hast du am Ende auch 4 Manager, die einem Entwickler sagen, was er wann machen darf :).

Gruß Kimmi

[Krishty]

Also, es ist so … normalerweise sind alle WinAPI- und NT-Funktionen in UTF-16 implementiert. Für viele neue Funktionen werden sogar gar keine ANSI-Äquivalente mehr angeboten. Generell rufen so ziemlich alle ANSI-Implementierungen die UTF-16-Versionen auf und konvertieren ihre Parameter vorher und nachher entsprechend (UTF-16-APIs zu benutzen ist deshalb fast immer effizienter als ANSI).

Wie gesagt bezieht sich das aber nur auf WinAPI und NT-Kernel. OutputDebugString() nutzt beides nicht wirklich: Es löst eine spezielle Ausnahme aus, die vom Debugger des Prozesses abgefangen wird, der daraufhin den String aus dem Speicher des unterbrochenen Threads liest. (Lässt sich als Anti-Debugging-Technik verwenden, weil sowohl das Auslösen der Ausnahme als auch einige Interna der Funktion über den Aufruf hinaus Wirkung haben.) So gesehen ist OutputDebugString() zwar in der Schnittstelle des Kernels, die Implementierung befindet sich aber im Debugger.

Würde man die Funktion intern auf UTF-16 umstellen, müsste man alle Debugger der Welt umschreiben.

Darum konvertiert die UTF-16-Variante (die nur zur Bequemlichkeit existiert, falls der Debugger mal Dateipfade ausspucken soll) alles zu ANSI und ruft die „normale“ Variante auf. Es ist halt keine Funktion, die man in fertigen Programmen einsetzen sollte, sondern nur eine ganz primitive Hilfe für Anwendungsentwickler.

Das erklärt die Weiterleitung von UTF-16 zu ANSI. Was die anderen Weiterleitungen betrifft:

1. Ein Sprung ist immer nötig, um eine Funktion in fremden DLLs aufzurufen. Also gehört (leider) einer in meine EXE.
2. Viele Leuten (solche wie ich) haben sich das „leider“ aus Punkt 1 zu Herzen genommen und die Funktionsadresse direkt eingetragen statt den Sprung zu nehmen. Darum lassen sich die Adressen der Funktionen in Kernel32.dll nicht mehr ändern (oder diese Anwendungen würden kaputtgehen). Man hat also an den entsprechenden Stellen Sprünge eingesetzt um zur neuen Implementierung weiterzuleiten.
3. Seit einigen Jahren ist der Windows-User-Mode-Kernel nicht mehr in Kernel32.dll sondern in KernelBase.dll. Darum ist die tatsächliche Implementierung hinter dem Sprung (auch diese Adresse haben einige Anwendungen fest verdrahtet) nur noch ein weiterer Sprung in Kernel32.dll.

Und an der Stelle frage ich mich, warum der Compiler nicht die Funktionsadresse fest einbaut: Sobald es einer getan hat, kann man die Adresse sowieso nicht mehr ändern. Was der Compiler tut, indem er „sich an die Regeln hält“ ist, dass er alle neuen Anwendungen dafür bestraft, dass sie nicht schummeln. Der nächste Layer kommt sowieso; aber statt nur die alten Anwendungen langsamer zu machen, macht man damit alle langsam.
(Falls man bei vier unbedingten Sprüngen in Folge von nennenswerter Verlangsamung sprechen kann.)

[kristof]

Boa, ich verwende zu viele Tastaturlayouts:

Zuhause nutze ich für den normalen Betrieb wegen der Umlaute das deutsche Tastaturlayout auf einer deutschen Tastatur. Fürs Programmieren stelle ich auf das Britische Layout um. Dort liegen fast alle (aber eben nicht alle!!) Sonderzeichen wie auf einer US Tastatur, allerdings hat das britische Layout, wie das deutsche, die große Enter Taste, was zu meiner deutschen Tastatur passt. Beides auf einem Mac. Das heisst Kommandos wie Copy und Paste funktionieren über die Command Taste. Die liegt da wo sonst die Windows Taste liegt.

Auf der Arbeit gibts nur US Tastaturen. Die sind fast genau so wie die britische, nur ist die Enter Taste kleiner und einige wenige Sondertasten liegen anders. Z.B. ist die #-Taste mit der "-Taste vertauscht. Aber als wäre das noch nicht schlimm genug handelt es sich bei dem Arbeitsrechner um eine Windows- bzw. Linux-Kiste. Das heisst Copy und Paste etc. geht über Strg... :D

Ich muss das unbedingt irgendwie vereinheitlichen. Momentan brauche ich egal wo ich los tippe immer so Zehn Minuten, in denen nur Zeichensalat entsteht, bis mein Hirn den Schalter umgelegt hat.

[Artificial Mind]

Perfect way to ruin an already ruined day:

#error <atomic> is not supported when compiling with /clr or /clr:pure.

Thanks, Microsoft!

[xq]

Gibt es für CLR/C++ nicht auch das "volatile"-Schlüsselwort aus C#, was die CLR zu atomic Verhalten zwingt?
ansonsten macht das schon bis zu einem gewissen grade sinn...

[Artificial Mind]

Also es gibt anscheinend Gründe weswegen <atomic> und <mutex> für C++/CLR nicht immer funktionieren. Aber für das bisschen std::atomic_flag was ich brauche, geht alles.

Deswegen:

Code: Alles auswählen

#undef _M_CEE
#include <atomic>
#define _M_CEE

[dot]

Hm, mein Vorschlag für einen möglichen Workaround: Pack deinen native Kram in eine Static Library und link die im CLR Projekt...

Edit: Noch einfachere Lösung natürlich, wie hier erwähnt: /clr einfach für alle rein native .cpp Files in einem Projekt separat abschalten...

[Artificial Mind]

Das machen wir bereits damit der Compiler nicht alles mit in den Managed Code zieht.
Haben CMake so konfiguriert, dass Dateien die auf .clr.cc enden automatisch das /clr Flag bekommen.

Trotzdem möchte ich auch die threadsafe static's in meinem C++/CLR Code nutzen ;)
Funktioniert übrigens einwandfrei.

[Krishty]

Visual C++-Ausnahmebehandlung:

  return ExceptionContinueSearch; // I don't think this value matters

  switch(__BuildCatchObjectHelper()) {
  case 1: _CallMemberFunction1();
  case 2: _CallMemberFunction2();

  /*
   * This function was compiled /EHs so we don't need to do anything in
   * this handler.
   */
  return ExceptionContinueSearch;

[Schrompf]

Den versteh ich nicht.

Was ich auch nicht verstehe: ich darf keine lokalen Funktionen in einer Funktion definieren, aber wenn ich das ganze als statische Funktion in einer lokalen Struktur definiere, geht es wieder. Und mit Lambdas wird die ganze Sache noch absurder. Pff.

Man merkt halt doch, dass C/C++ 30 Jahre Geschichte auf dem Buckel hat. Umso schöner ist das Arbeiten jetzt mit C++11 geworden. Und wenn sie jetzt noch das ganze #include-System irgendwie loswerden, wäre ich glücklich.

[Spiele Programmierer]

Du darfst in einer Funktion einfach keine Funktion deklarieren. Aus. Da ist eigentlich nichts unlogisch daran, dass ist einfach so und macht auch Sinn. Wenn du eine Funktion in eine Klasse machst, ist die Funktion in erster Linie in der Klasse, nicht aber in der Funktion und es erübrigt sich zum Beispiel die Frage nach der Interaktion mit dem lokalen Variablen. Lambdas sind eigentlich die Lösung auch für exakt dieses Problem, ich verwende sie selbst häufig dazu.

Mir wäre unbekannt es es zum Beispiel in Java oder C# anders wäre. Außer, dass man zusätzlich nicht mal mehr eine Klasse in einer Funktion definieren kann und man damit noch eingeschränkter ist. In Java zum Beispiel gab es scheinbar bis vor noch kürzerer Zeit noch nicht mal Lambdas.

Bei Includes stimme ich zu. Das Kostet sowohl mir als auch dem Compiler soviel Zeit... Inzwischen ist es eigentlich für mich mein absolut Top Feature Wunsch für C++17... Im Moment bin ich leider noch sehr skeptisch, wann es kommen wird.

[Artificial Mind]

Das ist schon unlogisch, denn lokale Helfer sind durchaus praktisch.
Lambdas funktionieren als Workaround, sind aber sicher nicht schön.

D unterstützt nested functions.

Es gibt sogar einen Wiki-Artikel dazu: http://en.wikipedia.org/wiki/Nested_function

[Spiele Programmierer]

Ich wüsste nicht, warum Lambdas weniger schön sein sollten? Ich verstehe auch nicht, welchen Sinn es machen würde, ein komplexes neues Feature einzubauen, wenn die gleiche Funktionalität schon sehr gut erreicht werden kann.

Möglicherweise ist es in D notwendig, bedingt wie Lambdas dort funktionieren.

[Artificial Mind]

Lambdas (und Function Literals) in D sind sogar noch etwas ausgeprägter als in C++: http://dlang.org/expression.html#FunctionLiteral

Lambdas sind mMn. eine unschöne Lösung, da das Lambda-Objekt durchaus Stack-Platz beansprucht.
Sehr wichtig ist auch direkt das Lambda-Objekt zu nutzen und keine std::function.

Point in Case:

Code: Alles auswählen

class A {
public:
	void foo()
	{
		int x = 0;
		auto f = [this, &x](){
			x += 2;
			this->bar();
		};
		std::function<void()> f2 = f;

		f();
		f2();

		std::cout << "Lambda size: " << sizeof(f) << " bytes" << std::endl;
		std::cout << "Function size: " << sizeof(f2) << " bytes" << std::endl;
	}

	void bar()
	{
		int x = 1;
		(void)x;
	}
};

Gibt aus:
x86:

Lambda size: 8 bytes
Function size: 24 bytes

x64:

Lambda size: 16 bytes
Function size: 32 bytes

Stacktrace von A::bar in erster Ausführung (lambda):

> ConsoleApplication3.exe!A::bar()
ConsoleApplication3.exe!A::foo::__l3::<lambda>()
ConsoleApplication3.exe!A::foo()
ConsoleApplication3.exe!wmain(int argc, wchar_t * * argv)

Stacktrace von A::bar in zweiter Ausführung (std::function):

> ConsoleApplication3.exe!A::bar()
ConsoleApplication3.exe!A::foo::__l3::<lambda>()
ConsoleApplication3.exe!std::_Callable_obj<void <lambda>(void),0>::_ApplyX<void>()
ConsoleApplication3.exe!std::_Func_impl<std::_Callable_obj<void <lambda>(void),0>,std::allocator<std::_Func_class<void> >,void>::_Do_call()
ConsoleApplication3.exe!std::_Func_class<void>::operator()()
ConsoleApplication3.exe!A::foo()
ConsoleApplication3.exe!wmain(int argc, wchar_t * * argv)

[dot]

Und jetzt nochmal im Release Build... ;)

[Artificial Mind]

Release Mode:

Lambda:

> ConsoleApplication3.exe!A::bar()
ConsoleApplication3.exe!A::foo()
ConsoleApplication3.exe!wmain(int argc=0, wchar_t * * argv=0x0000000000000000)

std::function:

> ConsoleApplication3.exe!A::bar()
ConsoleApplication3.exe!std::_Func_impl<std::_Callable_obj<<lambda_17d66e4a296a27b99474ba8caf0cc41c>,0>,std::allocator<std::_Func_class<void> >,void>::_Do_call()
ConsoleApplication3.exe!A::foo()
ConsoleApplication7.exe!wmain(int argc=0, wchar_t * * argv=0x0000000000000000)

Also ja, es ist im Release _etwas_ besser, das Lambda kann komplett geinlined werden, aber die std::function kann nicht komplett geinlined werden.

[Krishty]

Funktionieren Lambdas mittlerweile mit __forceinline? Dass es geinlinet werden kann nützt manchmal nichts, wenn man es nicht erzwingen kann.

Den versteh ich nicht.

Offensichtlich verstanden die Programmierer da auch selber nicht, was sie taten ;)

[dot]

Also ja, es ist im Release _etwas_ besser, das Lambda kann komplett geinlined werden, aber die std::function kann nicht komplett geinlined werden.

Besser als 0 Overhead geht's imo schwer!? Dass std::function nicht inlined werden wird, sollte hoffentlich jedem klar sein, der std::function verwendet... :P

[Artificial Mind]

Ich finde es ja schon sehr schön, dass der Lambda-Typ geinlined werden kann.