• $TID
  Die Thread ID des aktuellen Threads. Nützlich wenn man mehrere Threads debuggt und bestimmte Threads bei einem Breakpoint identifizieren muss.
• $HANDLES
  Die Anzahl der aktuell benutzen System-Handles des Prozesses. Handle Leaks lassen sich damit im Debugger leicht überwachen.
• $ERR
  GetLastError leicht gemacht. Schlägt ein WinApi Befehl fehl, dann ist es schön das man sofort beim Debuggen im Watch-Window sehen kann was die Ursache war. Oft genug ist ja im Code selbst kein Aufruf von GetLastError vorhanden oder nötig.

Siehe auch MSDN:
http://msdn.microsoft.com/en-us/library/ms164891.aspx

BTW: WinDbg hat noch einige mehr nette Pseudovariablen:
http://blogs.msdn.com/b/debuggingtoolbox/archive/2008/06/16/special-command-using-variables-and-retrieving-information-through-pseudo-registers.aspx
Schmerzhaft vermisse ich immer wieder $PEB, $TEB, $TPID, $RA im Visual Studio, komisch, dass es die nur im WinDbg gibt.

Aber wer weiß, vielleicht hat der eine oder andere doch die Frage wie er erkennen kann ob die ATL oder die MFC in einem Projekt Verwendung finden.

Vordefinierte Preprozessor Variablen gibt es dafür nicht, allerdings kann man erkennen ob die Standard ATL/MFCHeader in einem Projekt bereits als Include eingefügt wurden, denn in diesem Fall kann man die Existenz der Include-Guards prüfen.

Die MFC benutzt __AFX_H__ als Guard für die afx.h.
Die Basisklassen der ATL befinden sich in der atlbase.hund entsprechend lautet der Guard: __ATLBASE_H__.

Sofern also diese Guards definiert sind wurden auch die entsprechenden Libraries in der stdafx.h oder anderen Headern zuvor included.

Nachtrag 12.07.2011:
Stefan hat natürlich vollkommen recht mit seinem Kommentar, dass es die zwei Präprozessor-Variablen _MFC_VER und _ATL_VER gibt, die natürlich für den hier erwähnten Einsatz weitaus besser geeigent sind.
Siehe: http://msdn.microsoft.com/de-de/library/b0084kay.aspx
Ich habe hier den Wald vor lauter Bäumen nicht gesehen
Herzlichen Dank für diese produktive Ergänzung.

Diese Produktversion spiegelt auch auch in der vordefinierten Compiler Präprozessor Variable _MSC_VER wieder. Über diese Variable ist es zum Beispiel möglich verschiedene CRT oder STL Library Eigenarten abzufragen und entsprechen den eigenen Code für mehrere Compiler lauffähig zu machen. Gleiches gilt natürlich auch für den Code der MFC (siehe Anmerkung am Fuß der Tabelle).

Hier eine kleine Tabelle der Werte, die _MSC_VER für die verschiedenen Compiler annimmt mit ein paar zusätzlichen Hinweisen.

_MSC_VER  = Compiler
510  = C Compiler 5.1 (DOS)     - 1988?
       Mein aller erster Kontakt mit dem MS-Compiler
600  = C Compiler 6.x (DOS)     - 1990?
700  = C/C++ 7.0                - 1992
       Die UI war damals die PWB. MFC 1.0 wurde veröffentlicht
800  = Visual C++ 1.0           - 1993
       Existierte IMHO als 16bit und 32bit Compiler
900  = Visual C++ 2.0
       Existierte IMHO als 16bit und 32bit Compiler. MFC 3.0
1000 = Visual C++ 4.0           - 1995-03 ?
       Ab dieser Verison nur noch 32bit Compiler. MFC 4.0
???? = Visual C++ 4.1
       War nur für MSDN Subscriber verfügbar. Kam mit erstem Game/DirectX SDK.
???? = Visual C++ 4.2 und 4.21
       Erste Cross-Platform Version für Mac und PC. MFC 4.2, 4.21
1100 = Visual Studio 97 (5.0)   - 1997
       Enthielt weiterhin MFC 4.21
1200 = Visual C++ 6.0           - 1998-06
       Populärtse VC Version. MFC 6.0
1300 = Visual Studio.NET (2002) - 2002-02-13
       .NET hält Einzug. MFC 7.0
1310 = Visual Studio.NET 2003   - 2003-04-24
       MFC 7.1
1400 = Visual Studio 2005       - 2005-11-07
       MFC 8.0
1500 = Visual Studio 2008       - 2007-11-19
       MFC 9.0
1600 = Visual Studio 2010       - 2010-04-10
       MFC 10.0
1700 = Visual C++ 2011          - 2011 ???
       Produktname noch offen evtl. WinC++

Noch ein Hinweis auf _MFC_VER:
In der Tabelle habe ich nur die Versionen der zum Compiler passenden MFC Versionen aufgeführt. Die MFC setzt einen Define mit dem Namen _MFC_VER entsprechend. Dieser definiert ein WORD im Format 0xVVRR. Wobei VV für die Version der MFC steht in hexadezimaler schreibweise und RR für die Revision allerdings in dezimaler Schreibweise. Die aktuelle _MFC_VER von VS-2010 hat also den Wert 0x0A00 und in der MFC 4.21 wurde _MFC_VER als 0×0421 definiert.

PS: Auf die Idee für diese Tabelle kam ich durch eine Diskussion mit einem Teilnehmer auf der ADC für C++ in Prien, der auch schon x-Jahre mit dem MS-Compiler verbracht hat wie ich, und wir über die Entwicklung der Sprache C/C++ nachgedacht haben und was wann als Innovation unsere Programme veränderte. Eben ein typisches Bits+Bytes Gespräch…

• Rechte auf dem TFS verwalten (Team Foundation Roles)
• Rechte auf dem SharePoint Server verwalten (SharePoint Roles)
• Rechte auf dem SQL Reporting Server verwalten (Reporting Services Roles)

Wenn also was nicht klappt, weil einem zum Beispiel ein Report nicht angezeigt wird, ist man gleich wieder am grübeln: Wo war das nochmal mit den Reporting Services? Welcher Server, welche Webadresse? Gleiches, wenn man ein Benutzer keinen Zugriff auf die Dokumente in der SharePoint Site hat, die zu einem Projekt angelegt wurde.

Ich fühle mich eigentlich eher als Entwickler, denn als Administrator von einem SharePoint Server oder SQL-Reporting Services Server.

Das Ganze wird um ein vielfaches einfacher durch das TFS Administration Tool 2.1.
Hier kann man auch einfache Art in einem Tool alle Rechte auf einmal einsehen und verwalten. Netterweise wird man in der Listenanzeige sofort durch rote Kästchen auf die Konten aufmerksam gemacht, in denen keine Rechte definiert wurden. In den meisten Fällen ist hier auch schon ein grundsätzliches Problem gefunden.

Das Tool lässt sich auf jedem Client installieren auf dem der Team-Explorer auch installiert wurde.

Link: http://tfsadmin.codeplex.com/

Ich zumindest habe teilweise Kommentare, die sich über 10 bis zu 100 Zeilen erstrecken. Die sind nah am Code und erklären, oft was die Hintergründe für das gewählte Design und Vorgehen sind.

Leider ist aber der Editor vom Visual Studio kein Word. D.h. absatzweisen Umbruch kennt das Ding nicht und manuell solche Texte inkl. Einrückungen und Listen mit Bindestrichen oder 1., 2., 3. zu formatieren ist etwas was gar keinen Spaß macht. Zudem sind die Kommentar Zeichen // oder * eher lästig als hilfreich beim schreiben.
Und auch VAX muss hier mal passen. Aber! Netterweise gibt e auch andere Addins.

Ich habe vor langer Zeit schon den Comment Reflower  entdeckt. Mit dem ist das Ganze ein Klacks.
Aus dem nachfolgenden Text:

// Dies ist ein Kommentar, den man nicht wirklich hier schreiben
// müsste und der
// eigentlich nichts bedeutet außer
// die Funktionen von einem netten Addin zu zeigen.
// Das
//  1. wirklich Arbeit erspart
//  2. total simpel zu bedienen ist
//  3. für alle VS-Versionen von 2005 über 2008 bis 2010 verfügbar ist.
// Was bei der Formatierung heraus kommt lässt sich sehen.

Wird in Null-Komma-Nichts der folgende Text:

// Dies ist ein Kommentar, den man nicht wirklich hier
// schreiben müsste und der eigentlich nichts bedeutet
// außer die Funktionen von einem netten Addin zu
// zeigen. Das
//  1. wirklich Arbeit erspart
//  2. total simpel zu bedienen ist
//  3. für alle VS-Versionen von 2005 über 2008 bis
//     2010 verfügbar ist.
// Was bei der Formatierung heraus kommt lässt sich
// sehen.

Wer noch mehr Beispiele sehen will, was das Tool leistet findet hier auf der Sourceforge Seite ein Vorher Nacher Pärchen.

Das Addin existiert für alles Visual Studio Versionen ab 2005.
Es kann hier heruntergeladen werden:

• VS-2005: http://commentreflower.sourceforge.net/
• VS-2008 und VS-2010: http://www.kynosarges.de/CommentReflower.html

PS: Es empfiehlt sich ein Blick auf die Blockdefnition in den Einstellungen. Dort ist oft ein Leerzeichen hinter dem * bzw. // eingetragen. Leider lässt sich in meiner Version hier RegEx nicht einschalten. Wer also ein <tab>-Zeichen hinter dem * oder // hat wird sich wundern wenn das Addin keinen Kommentar findet. Ich habe das Leerzeichen einfach entfernt…

PPS: Für alle nicht C++ Entwickler. Das Tool funktioniert auch für VB und C#

Das Erste was ich sofort vermisst habe war in der folgenden Reihenfolge:

1. Dynamic Help
2. Table of contents (TOC)
3. Sync to TOC
4. Index
5. Filter
6. Direkte Suche in VS, oder dem entsprechenden Viewer

Ich bin dann auf im Internet auf die Suche gegangen und wurde mit 2 Tools fündig, die einem hier helfen können:

HelpViewerKeywordIndex

Aber wie angekündigt soll es auch hier Verbesserungen geben. Und das außerhalb der Wartungszyklen des VS (siehe Video unten mit Ryan Linton). Zumindest was den Index betrifft und die Suchmöglichkeit innerhalb von VS betrifft schafft ein kleines Tool von Ryan Linton (wie versprochen seit dem 20.04.) wenigstens etwas Abhilfe, der HelpViewerKeywordIndex.

Mit diesem Tool erhält man zumindest mal wieder den Index und ein Suchfenster in VS.
Auch dass das Sucherergebnis in einen VS-Fenster angezeigt werden kann ist nett. Leider betrifft diese Einstellung nicht die Funktion der F1-Taste. In diesem Fall wird immer noch der externe Browser angeworfen und nicht der interne, oder ich habe die Einstellung nicht gefunden wo man mit der F1-Taste ein Browser Fenster in VS öffnet.
Ganz verstanden habe ich auch die Option “Display TOC in page” nicht.
Das Tool ist zumindest mal ein kleiner Schimmer eines eventuellen zukünftigen Lichtblicks

Aber wer weiß, vielleicht lässt Version 1.1 von  HelpViewerKeywordIndex nicht lange auf sich warten.

H3Viewer

Mit H3Viewer, von meinem MVP-Kollegen Rob Chandler, bekommt man zumindest mal wieder das, was man in VS-2008 auch hatte. Table of Contents, Sync to contents. Und der Viewer ist nicht im Browser. Mit dem Ding lässt sich leben oder zumindest ersetzt es den Viewer den wir aus VS-2005/8 kannten ziemlich gut. Und ja, es gibt auch hier wieder Bookmarks, die jetzt keine Favoriten Einträge im Browser sein müssen
Besonders gefreut habe ich mich auch über die Funktion im Index die Doubletten zum gleichen Stichwort im Index in einem separaten Fenster wieder angezeigt zu bekommen, denn nicht jeder Treffer zu GetWindowtext ist der den ich suche.
Nett auch die TTS Funktion (Text to Speech)
Hier fehlen jetzt eigentlich nur noch die Filter zum vollständigen Glück.

Aber wer weiß, was Microsoft uns demnächst noch zu bieten hat. Laut der Homepage von H3Viewer hat Microsoft noch bereits einige andere Viewer in der Schublade.

Siehe auch:
http://channel9.msdn.com/posts/kmcgrath/Help-30-New-Help-System-in-Visual-Studio-2010/

Links:
http://visualstudiogallery.msdn.microsoft.com/en-us/4af86641-a302-4edf-9853-007bcc670b30
http://mshcmigrate.helpmvp.com/viewer

Netterweise hilft einem eine Funktion, die man nur von Blöcken und verschachtelten Funktionen her kennt Strg+´ (Edit.GotoBrace). Wichtig! Man darf nicht auf der Variable oder Bedingung stehen, sondern muss auf dem Schlüsselwort stehen.

Wenn man auf einer Präprozessor Direktive kann man mit den Tasten die einem zur passenden Klammer bringt zur nachfolgenden Direktive. Und mit dem Festhalten der Umschalttaste kann man den entsprechenden Block auch markieren.

Üblicherweise wählt der Debugger eine Darstellungsform, die für die Variable geeignet ist. Besonders für STL Datentypen hat sich hier einiges getan seit VC-2005.

Dennoch kann man dem Debugger für manche Datentypen noch einen Format Specifier mitgeben, der einem die Arbeit beim Debuggen extrem erleichert.
Format Specifier erlauben es eine Variable entsprechend Ihrer Verwendung zu interpretieren. Typisch hier wäre eine Windows Nachricht. Als Integer sagt einem 0×0129 nicht viel, aber WM_NCCREATE einiges. Wenn man hinter die Variable nMsg im Watch-Fenster einfach aus nMsg,wm erweitert erhält man sofort die Nachricht als symbolischen Wert angezeigt.

Ich will hier nicht alle aber wenigstens ein paar sehr nützliche und weniger bekannte Format Specifier aufzählen:

! – Raw format
hr – HRESULT in Klartext
su -Unicode
s8 – UTF8
wm – Windowsnachricht
wc – Fensterstil
<n> – Anzahl der Arrayelemente

Am schönsten sieht man die Wirkung an dem folgenden Code und den nachfolgenden Bildern der Watch-Windows:

int g_ai[] =
{
  4711,
  815,
  1234
};
 
int _tmain(int argc, _TCHAR* argv[])
{
  std::list lst;
  lst.push_back(1);
  lst.push_back(2);
  DWORD dwHResult = 2147943623;
  void *szUnicode = L"Unicode ÄÖÜäöü";
  char *szUTF8Code = "Umlaute AE=\xc3\x84 OE=\xc3\x96 UE=\xc3\x9c.";
  UINT winmsg = 125;
  DWORD winstyle = 0xA6730000;
  int *pi = g_ai;
 
  DebugBreak();
  return 0;
}

Hier das Ganze die Daten im Watchwindow ohne Formatspecifier:

Hier das Ganze mit:

Weitere Links dazu:
http://msdn.microsoft.com/en-us/library/75w45ekt.aspx
http://blogs.msdn.com/vcblog/archive/2006/08/04/689026.aspx

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.

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());
}