VS-Tipps & Tricks: Direkter Break in den Debugger bei einem ASSERT

ASSERTs in der MFC und in der CRT sind tolle Hilfsmittel, aber nicht selten verfälschen sie auch das Problem alleine dadurch, dass ein Fenster aufpoppt, wenn der ASSERT zuschlägt. Hat man nun einen Code, der in einem Tooltipp etwas Böses macht, dann wird der Tooltipp selbst aber schon wieder durch das erscheinen der ASSERT Meldung zerstört. Oder es wird ein neuer ASSERT ausgelöst. Der Callstack wird dadurch oft schwer zu lesen.
Besonders heikel kann dies auch noch werden wenn man mehrere Threads hat. Gleichfalls problematisch ist, dass in dem Moment in dem die ASSERT Box auftaucht nun auch wieder alle Timer weiterlaufen und sehr eigentümliche Seiteneffekte weiter auslösen können, dito. Probleme in WM_PAINT Handlern, denn auch die lösen evtl. schon wieder Aktionen aus, die Variablen verändern.

Nett ist am ASSERT-Dialog natürlich die Möglichkeit Ignorieren zu sagen und das Programm weiter laufen zu lassen. Ganz besonders wenn man Debug Versionen im Testfeld mit Anwendern testet.

Dennoch bin ich bei Debug-Versionen dazu übergegangen ASSERTs direkt  crashen zu lassen, bzw. direkt einen Debug-Break auszulösen. Das erleichtert das Lesen des Crashdumps bzw. hilft auch beim Debuggen, weil man direkt an der Stelle steht wo es hakt und alle Fenster und Variableninhalte exakt noch so sind, wie Sie es beim Auftreten des Problems waren (Tooltips, Popups, Menüs etc.).

Der Code um das zu erreichen ist relativ simpel. Man verwendet dazu _CrtSetReportHook2. In dem Hook sagt man einfach was man gerne hätte. Nämlich bei einem ASSERT oder ERROR keinen Dialog sondern einen Break (INT3).

#ifdef _DEBUG
int __cdecl DebugReportHook(int nReportType, char* , int* pnRet)
{
  // Stop if no debugger is loaded and do not assert, cause a crash
  // - returning TRUE indicates that we handled the problem, so no other hook
  //   needs to perform any action
  // - setting the target of *pnRet to TRUE indicates that the CRT should
  //   execute an INT3 and should crash or break into the debugger.
  return *pnRet = nReportType==_CRT_ASSERT ||
                  nReportType==_CRT_ERROR ?
                            TRUE : FALSE;
}
#endif

void SetBreakOnAssert(BOOL bBreakOnAssert/* =FALSE */)
{  
// Need to disable the ASSERT handler?
#ifdef _DEBUG  
  if (bBreakOnAssert)   
    _CrtSetReportHook2(_CRT_RPTHOOK_INSTALL, DebugReportHook); 
  else   
    _CrtSetReportHook2(_CRT_RPTHOOK_REMOVE, DebugReportHook);
#else
  UNUSED_ALWAYS(bBreakOnAssert);
#endif
}

Durch diese kleine Funktion SetBreakOnAssert kann man dieses Verhalten nun einfach ein- und ausschalten. Nähere Details stehen im Kommentar der Hook-Funktion.

VS-Tipps&Tricks: Einfache Debug-Ausgabe mit TRACE auch in der Release Version

Wer wollte nicht schon immer mal gerne TRACE (Debug)-Ausgaben in seinem Release Programm haben ohne dafür überall OutputDebugString reinschreiben zu müssen.

Die nachfolgene kleine Klasse macht es möglich, den gewohnten Syntax des MFC TRACE Makros zu verwenden und direkt auf die Debugausgabe umzuleiten:

//    CTraceToOutputDebugString
//        Is a nice replacment class for TRACE
//        Easy to use with:
//            #undef TRACE
//            #define TRACE    CTraceToOutputDebugString()

class CTraceToOutputDebugString
{
public:
    // Non Unicode output helper
    void operator()(PCSTR pszFormat, ...)
    {
        va_list ptr;
        va_start(ptr, pszFormat);
        TraceV(pszFormat,ptr);
        va_end(ptr);
    }

    // Unicode output helper
    void operator()(PCWSTR pszFormat, ...)
    {
        va_list ptr;
        va_start(ptr, pszFormat);
        TraceV(pszFormat,ptr);
        va_end(ptr);
    }

private:
    // Non Unicode output helper
    void TraceV(PCSTR pszFormat, va_list args)
    {
        // Format the output buffer
        char szBuffer[1024];
        _vsnprintf(szBuffer, _countof(szBuffer), pszFormat, args);
        OutputDebugStringA(szBuffer);
    }

    // Unicode output helper
    void TraceV(PCWSTR pszFormat, va_list args)
    {
        wchar_t szBuffer[1024];
        _vsnwprintf(szBuffer, _countof(szBuffer), pszFormat, args);
        OutputDebugStringW(szBuffer);
    }
};

Durch den obenstehenden Code kann man auch in einer Release Version Trace Ausgaben erzeugen und z.B. mit DebugView.exe (Sysinternals) sichtbar machen, ohne evtl. weitere Anpassungen vornehmen zu müssen:

// Activate my special tracer
#undef TRACE
#define TRACE    CTraceToOutputDebugString()

void Foo()
{
     // Sometime usefull to see the output in a release version too
     TRACE(__FUNCTION__ " called at %d\n", GetTickCount());
}

CMapStringTo… HashKey Implementierung in VC-2003/5/8 ist auch fragwürdig

 Hash-Algorithmen haben es mir irgendwie angetan. 1984 hatte ich das erste mal mit einem miesen Hashverfahren zu tun, das einfach versagte wenn es nur um Ziffern ging. Das ganze betraf das Betriebssystem OASIS (später TheOS) und dessen Index Dateiorganisation. Ich entwickelte hierfür einen Patch in Assembler, der damals exakt in den x-Bytes der Kernels in Z80 Assembler passen musste.
Das Problem bei Strings die nur aus Ziffern bestehen ist das die Veränderung, die immer nur die unteren 4 Bits betrifft und die höheren 4 Bits immer konstant sind mit 3 belegt sind.

Als ich gelesen habe,  dass in VS-2010 die CMap Implementierung nun auch für Strings den selben Algorithmus aus der STL erhalten, habe ich mir auch den mal genauer angesehen. (siehe Beitrag Die MFC erhält mit VC-2010 jetzt eine neue HashKey Implementierung)
Der sieht so aus:

inline UINT CMapStringToString::HashKey(LPCTSTR key) const
{
  UINT nHash = 0;
  if (key == NULL)
  {
    AfxThrowInvalidArgException();
  }
 
  while (*key)
    nHash = (nHash<<5) + nHash + *key++;
  return nHash;
}

Und auch in diesem Fall muss ich sagen, dass der Algorithmus nur scheinbar intelligent ist. Wenn man sich aber die Abstände die hier erzeugt werden etwas genauer anschaut kommt man schnell auf eine Wertekombination, in der der Algorithmus versagt.
Wie sehr er versagt zeigt das folgende Beispiel, in dem ich einfach einen String verwende der aus 5 Ziffern besteht und immer den Abstand 11 verwendet.

CMapStringToPtr myMap;
for (int i=0; i<1000; i+=11)
{
  CString strKey;
  strKey.Format(_T("%05d"),i);
  myMap[strKey] = NULL;
}

Das erschreckende Ergebnis der Verteilung ist bei einem Unicode wie auch MBCS Projekt:

TMyMap<class CMapStringToPtr>::DumpMap
Bucket  0 =  0
Bucket  1 =  0
Bucket  2 =  0
Bucket  3 =  0
Bucket  4 =  0
Bucket  5 =  0
Bucket  6 =  0
Bucket  7 =  0
Bucket  8 = 36
Bucket  9 =  0
Bucket 10 =  0
Bucket 11 =  0
Bucket 12 =  0
Bucket 13 =  0
Bucket 14 = 55
Bucket 15 =  0
Bucket 16 =  0

Wie gut, dass auch die String Variante von HashKey überarbeitet wird.

BTW: Da die internen Strukturen protected sind muss man zu einem kleinen Trick greifen um die Verteilung ausgeben zu können. Ich habe dazu ein template verwendet, dass für alle MFC Maps funktioniert.

template<class TBase> class TMyMap : public TBase
{
public:
  void DumpMap()
  {
    TRACE(__FUNCTION__ "\n");
    if (m_pHashTable)
    {
      for (size_t i=0; i<m_nHashTableSize; ++i)
      {
        int iCount = 0;
        for (CAssoc *p = m_pHashTable[i]; p; p=p->pNext)
          ++iCount;
        TRACE("Bucket %2d = %4d\n", i, iCount);
      }
    }
  }
};

Merke: Wer Hashes verwendet sollte sich über sein Hashverfahren wirklich gedanken machen.

BTW: Sollte es den Leser meines Blogs langsam langweilen weil ich mich permanent mit Hash-Algorithmen aufhalte, der sei getröstet: Dies war vorläufig mein letzter Beitrag zu CMap… :mrgreen:

Die MFC erhält mit VC-2010 jetzt eine neue HashKey Implementierung

Ich hatte die schlechte Hashkey Implementierung ja bereits in VC-2005 als Bug gemeldet (siehe Die HashKey Implementierung in der MFC in VC-2005 und VC-2008). In VC-2008 geschah dies bzgl. wieder nichts. Aber was lange währt wird manchmal gut 😉

Die neue Implementierung wird aus der aktuellen STL übernommen. Diese Implementierung sorgt für Integer und Pointer für eine sehr gute zufällige Verteilung. Und weitere gute Nachricht dazu, auch die Implementierung für Strings wird aus der STL übernommen.

Zitat:

Hello Martin,

Thanks for the report. This issue has been fixed in MFC for Visual Studio 2010. MFC now uses the STL hash functions directly when possible, or uses a new algorithm copied from STL (in the case of strings).

Pat Brenner
Visual C++ Libraries Development
Von Microsoft am 20.07.2009 um 12:15 bereitgestellt

Siehe https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=468860

Tipps & Tricks: Warum nicht mal ein anderer Font, wie z.B. Consolas

Eigentlich bin ich sehr konservativ was meine Visual-Studio Einstellungen betrifft. Aber irgendwie hat mich heute mal die Experimentierlaune überkommen, weil ich durch Zufall über einige Color-Schemes gestolpert bin und im C++ Forum eine Diskussion lief ob „hell auf dunkel“ oder „dunkel auf hell“ besser ist.

Am Ende des Experimentierens, habe ich das Farbschema gelassen wie es ist. Ich habe ja auch VA-X, den untentbehrlichen Helfer des Programmieres,  und auch da ist bis auf das Highlighting alles Standard. Aber bei der Schriftart habe ich – für mich gefühlt – was besseres gefunden: „Consolas“.
Eindeutig für mich das schönere Schriftbild, klarer und etwas kompakter und kleiner als „Courier New“.

Beispiel „Courier New“
CourierNew

Beispiel „Consolas“
Consolas
Wer mag, der kann es gleich probieren. Auf meinen Vista Rechnern war diese Schriftart sofort vorhanden. Wer das Font-Paket nicht hat, der kann es herunterladen bei Microsoft Consolas Font Pack for Microsoft Visual Studio 2005 or 2008

Die HashKey Implementierung in der MFC in VC-2005 und VC-2008

Die Maps in der MFC werden ja auch zum Teil gerne verwendet. Auch wenn viele Programmierer eher auf die std::map bzw. std::hash_map verwenden.

Zwei interne Dinge sind jedoch vielen Entwicklern nicht klar.

  1. Die Standard-Maps der MFC werden mit 17 Hash-Buckets erzeugt. Man sollte sich also über die Anzahl der Elemente klar werden, die gespeichert werden sollen.
    Bei großen Datenmengen sollte man evtl. darüber nachdenken, die Anzahl der Buckets zu erhöhen.
  2. Ist die Hash Funktion zu beachten, die hier verwendet wird. Denn deren Effektivität entscheidet ja, wie die Einträge auf die Buckets verteilt werden.

Zu diesem zweiten Punkt macht man eine erstaunliche Entdeckung, wenn man sich ansieht, was Microsoft für eine Funktion vorgesehen hat um den Hask-Key zu erzeugen. Diese Funktion ist in der MFC für primitive Werte vordefiniert, als primitive Werte sehe ich alle numerischen Werte, Zeiger und Handle an.
Man findet eine Implementierung als Template-Funktion in afxtempl.h:

template<class ARG_KEY>
AFX_INLINE UINT AFXAPI HashKey(ARG_KEY key)
{
 // default identity hash - works for most primitive values
 return (DWORD)(((DWORD_PTR)key)>>4);
}

Das erstaunliche ist für mich, dass hier die untersten 4 Bits einfach abgeschnitten werden. Für mich hätte für Handles, Zeiger und Integer Werte einfach ein cast gelangt.

Nehmen wir jetzt mal an, wir haben eine einfache Datenmenge, die die Integer 1-100 auf eine Struktur abbilden. Man wird die erstaunliche Entdeckung machen, dass alle Werte nur in den Buckets 0-6 abgespeichert werden. Die Buckets 7 bis 16 werden nicht verwendet.

Der Nachteil ist offensichtlich. Man nutzt das Datenrauschen auf den untersten 4 Bits nicht.
Das macht sich sogar bei Fensterhandles bemerkbar. Bekanntlich sind das immer gerade Werte, aber auch auf den Bits 1-3 finden wir hier Informationen. Auch hier werden nützliche „zufällige“ Informationen nicht genutzt. Dadurch werden mehr Kollisionen in Kauf genommen als notwendig wären.

Ich möchte nicht unerwähnt lassen, dass die MFC Maps wirklich eine Berechtigung haben, weil sie grundsätzlich einen Pool-Allocator verwenden. Häufige Allokationen und Löschungen werden weitaus schneller behandelt, als durch die std::map, oder std::hash_map mit normalen Allocator.

Ich habe diesen Bug (oder miese Verhalten) bereits in der Beta für VC-2008 gemeldet. Es wurde aber nicht mehr geändert. Nun habe ich es an die Produktgruppe erneut  für VC-10 eingereicht.
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=100772
Nachtrag 22.06.2009: Da der Bug von Microsoft nicht neu geöffnet wird habe ich einen neuen für VS-2010 Beta 1 angelegt.
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=468860
Wer Lust hat, der kann ja abstimmen.

BTW: Die HaskKey Funktion in afxtempl.h ist für andere Maps (z.B. CMapPtrToPtr) direkt in der Klasse definiert. Dieses Template wird nur vom CMap-Template verwendet.

Neue MSDN Foren nun auch in Deutsch

In der englisch sprechenden Welt haben die MSDN Foren den NNTP Foren weitgehend den Rang abgelaufen.
Mit dem Launch von VS-2005 gab es auch den Versuch diese in Deutsch zu starten, was aber wirklich in die Hose ging, mangels Werbung, Angebot, Verweis und Akzeptanz der Pros und Regulars. Es wurden hier gerade einmal Untergruppen für die Visual-Express Versionen geschaffen. Dieses alte Forum ist noch zu finden unter:
http://forums.microsoft.com/msdn-de/default.aspx?siteid=9
Nicht mal 1000 Threads 6 Bereichen in mehr als 3 Jahren sind ein ziemlich müdes Ergebnis.

Nun wird ein zweiter Versuch gemacht mit einem weitaus größeren Angebot unter
http://social.msdn.microsoft.com/Forums/de-DE/categories/
Der Inhalt der alten Foren wurde auch in die neuen Foren Bereiche migriert.

Der Vorteil gegenüber dem alten System ist offensichtlich:

  • Im alten System waren die Threads und Foren nach Sprache getrennt. Im neuen System erscheinen alle Threads über alle MSDN Foren aller Sprachen in einer Liste.
  • Die UI hat sich entschieden verbessert.
  • Ein Bewertungsbereich und Scoring Bereich für die Mitglieder wurde erweitert.
  • … und scheinbar wird auch versucht etwas mehr Werbung zu machen.

Nun bleibt abzuwarten ob diese Foren wirklich genutzt werden für C++ und Visual Studio allgemein. Oder ob die C++ Regulars lieber doch auf NNTP mit nntp://microsoft.public.de.vc verbleiben oder das bekannte Forum auf http://www.c-plusplus.de/forum nutzen. Über die Niveauunterschiede zwischen diesen beiden Foren brauche ich nichts zu sagen 😉 …

Anmerkung:
Ein Anachronismus ist sicherlich, dass man über die Community Links in der lokalen MSDN Installation oder auch über die Menüpunkte im Visual Studio (MSDN-Foren) sowohl bei der 2005er wie auch der 2008er Version, immer noch nur das alte Englische MSDN Forum erreicht, dass auch schon längst abgelöst wurde, und das man aktuell keine Möglichkeit hat aus VS, die deutschen Communities zu erreichen.
Ich frage mich manchmal warum die Community Aktivitäten von Microsoft, gerade im nicht Englisch sprechenden Bereich, selten einmal koordiniert erscheinen. Es kommt mir so vor, als ob die Betreuung dieser Bereiche einfach jemanden aufgedrückt wird, der genug Anderes zu tun hat und diese Bereiche eher nebenbei betreuen „muss“… und auf Befehl von irgendwo oben wird dann eben mal mit Hauruck „Irgendwas“ gemacht, weil man muss ja mal was machen…

VS Tipps & Tricks: Der unbekannte CString Konstruktor…

CString nimmt natürlich auch in einem seiner Konstruktoren einen LPCTSTR . Dieser Konstruktor hat aber noch eine versteckt eingebaute Funktion. Man kann CString auch mit MAKEINTRESOURCE(id) verwendet. Aus der Dokumentation geht dies nicht eindeutig hervor, aber zumindest findet man es am Rande erwähnt.
Ist also das High-WORD des LPCTSTR gleich NULL dann wird das LOWORD verwendet um die entsprechende String-Ressource zu laden.
Ist die Ressource nicht vorhanden wird in der Debugausgabe ein entsprechender Trace erzeugt.

Benötigt man also temporär eine String Variable so kann man direkt in einem Statement die entsprechende String-Resource laden:

CString strMyText(MAKEINTRESOURCE(IDS_MY_STRING));
strMyText += strSomeOther;
strMyText += CString(MAKEINTRESOURCE(IDS_MY_TEXT_TO_APPEND));

VS Tipps & Tricks: Export/Import von Einstellungen zwischen VisualStudio 2005 und 2008

In einem meiner ersten Tipps habe ich das Thema Import und Export von Einstellungen schon behandelt schon behandelt: VS-Tipps & Tricks: Einstellungen für Visual Studio mehreren Arbeitsplätzen gleich halten.

Besonders wichtig ist das für mich immer mit den Tastatureinstellungen, die immer anpasse.

Was ich aber jetzt mit positivem Erstaunen feststellen konnte ist folgendes:
Man kann Einstellungen auch aus VS-2005 nach VS-2008 übertragen und umgekehrt ❗

Die XML Struktur des Exportformates ist nicht versioniert. Man kann direkt Einstellungen aus VS-2005 austauschen. Ideal wenn man Legacy Projekte noch behandeln muss und beide Systeme parallel fährt.

MSVSMON: Visual Studio Remote Debugging Monitor will not be able to debug applications because…

Da schreibe ich einen netten Artikel über Remote Debugging und schon geht es doch nicht so einfach wie ich schreibe.

Manch ein Entwickler wird von der folgenden Nachricht begrüßt, wenn er MSVSMON.EXE startet:

Visual Studio Remote Debugging Monitor will not be able to debug applications because the ‚Network access: Sharing and security model for local accounts‘ local security policy option is set to ‚Guest only – local users authenticate as Guest‘. This can be configured with the ‚Local Security Settings‘ administration tool.
Do you want to continue?    (Use /noguestonlywarn to suppress this warning)

Nun auch keine Tragik. Dann kommen wir aber um einen Neustart nach Änderungen der Lokalen Richtlinien nicht herum. Aber man muss erst mal wissen was mit dieser Meldung gemeint ist, wenn man ein deutsches OS benutzt:

  1. Systemsteuerung starten.
  2. Leistung und Wartung -> Verwaltung -> Lokale Sicherheitsrichtlinie
  3. In den Lokalen Sichereinstellungen auf
    Lokale Richlinien -> Sicherheitsoptionen
  4. Dort dann Netzwerkzugriff: Modell für gemeinsame Nutzung und Sicherheitsmodell für lokale Knoten auswählen.
  5. Umstellen auf: Klassisch – lokale Benutzer authentifizieren sich als sie selbst
  6. Reboot

HTH
Siehe auch:
How to: Set Up Remote Debugging
How to debug on computers that are running Windows XP and that are in the same Workgroup in Visual Studio .NET or in Visual Studio 2005