Man sollte auch seine Backups backuppen. Ich habe letztes Wochenende gemerkt, dass meine vor 15 Jahren gebrannten CDs unlesbar geworden sind.
Re: Jammer-Thread
Verfasst: 15.09.2014, 16:09
von Spiele Programmierer
CDs sind zum Backup größerer Mengen auch ungeeignet.
Re: Jammer-Thread
Verfasst: 15.09.2014, 16:27
von 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).
Re: Jammer-Thread
Verfasst: 16.09.2014, 15:21
von 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.
Re: Jammer-Thread
Verfasst: 16.09.2014, 15:33
von 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.
Re: Jammer-Thread
Verfasst: 16.09.2014, 16:18
von Krishty
Wenn du von Steuern leben willst statt sie zu bezahlen, entwickel halt Kampfdrohnen, Bundestrojaner, oder Hartz-IV-Kontrollsysteme!
Re: Jammer-Thread
Verfasst: 16.09.2014, 19:55
von 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.
Re: Jammer-Thread
Verfasst: 23.09.2014, 00:08
von Krishty
Das Wochenrätsel: Welche Maschinenbefehle erzeugt Visual C++ 2013 für diese Zeile?
auto tickDuration = 1.0 / double(Windows::QueryPerformanceFrequency());
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:
Wie mich diese UNicode-Hüllen in VS nerven, passt hier leider auf keine Seite :).
Gruß Kimmi
Re: Jammer-Thread
Verfasst: 23.09.2014, 09:37
von dot
Wtf, OutputDebugStringW called OutputDebugStringA :o
Ist das eine 32-Bit Anwendung auf einem 64-Bit System? Sieht nämlich irgendwie danach aus... ;)
Re: Jammer-Thread
Verfasst: 23.09.2014, 10:04
von 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
Re: Jammer-Thread
Verfasst: 23.09.2014, 10:14
von 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:
Ein Sprung ist immer nötig, um eine Funktion in fremden DLLs aufzurufen. Also gehört (leider) einer in meine EXE.
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.
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.)
Re: Jammer-Thread
Verfasst: 23.09.2014, 18:02
von 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.
Re: Jammer-Thread
Verfasst: 23.09.2014, 19:38
von Artificial Mind
Perfect way to ruin an already ruined day:
#error <atomic> is not supported when compiling with /clr or /clr:pure.
Thanks, Microsoft!
Re: Jammer-Thread
Verfasst: 23.09.2014, 20:20
von 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...
Re: Jammer-Thread
Verfasst: 23.09.2014, 20:32
von 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.
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...
Re: Jammer-Thread
Verfasst: 23.09.2014, 22:18
von 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.
Re: Jammer-Thread
Verfasst: 25.09.2014, 12:47
von 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;
Re: Jammer-Thread
Verfasst: 25.09.2014, 15:44
von 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.
Re: Jammer-Thread
Verfasst: 25.09.2014, 17:28
von 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.
Re: Jammer-Thread
Verfasst: 25.09.2014, 19:30
von Artificial Mind
Das ist schon unlogisch, denn lokale Helfer sind durchaus praktisch.
Lambdas funktionieren als Workaround, sind aber sicher nicht schön.
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.
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.
Also ja, es ist im Release _etwas_ besser, das Lambda kann komplett geinlined werden, aber die std::function kann nicht komplett geinlined werden.
Re: Jammer-Thread
Verfasst: 26.09.2014, 11:09
von Krishty
Funktionieren Lambdas mittlerweile mit __forceinline? Dass es geinlinet werden kann nützt manchmal nichts, wenn man es nicht erzwingen kann.
Schrompf hat geschrieben:Den versteh ich nicht.
Offensichtlich verstanden die Programmierer da auch selber nicht, was sie taten ;)
Re: Jammer-Thread
Verfasst: 26.09.2014, 11:44
von dot
Artificial Mind hat geschrieben: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
Re: Jammer-Thread
Verfasst: 26.09.2014, 11:50
von Artificial Mind
Ich finde es ja schon sehr schön, dass der Lambda-Typ geinlined werden kann.