MSDN Magazin > Home > Ausgaben > 2007 > June >  C++: Einblicke in die nächste Generation v...
C++
Einblicke in die nächste Generation von Visual C++
Tarek Madkour

Dieser Artikel basiert auf einer Vorabversion von Visual Studio Codename „Orcas“. Änderungen der Informationen in diesem Artikel sind vorbehalten.
Themen in diesem Artikel:
  • Ausrichten von Anwendungen auf Windows Vista
  • Verbesserungen an MFC
  • Vorbereiten von Anwendungen für UAC
  • Marshalling systemeigener und CLR-Typen
In diesem Artikel werden folgende Technologien verwendet:
Visual C++, Visual Studio
Windows Vista™ macht zur Erweiterung der Windows®-Plattform Tausende neuer systemeigener APIs verfügbar. Diese APIs ermöglichen Entwicklern, ansprechendere Benutzeroberflächen und reaktionsfähigere E/A-Vorgänge zu erstellen, Threads wirksamer zu verwalten und vieles mehr. Die nächste Version von Visual Studio® Codename „Orcas“ wird C++-Entwicklern helfen, die Vorteile der neuen Funktionen in Windows Vista optimal zu nutzen. Dies wird durch Bereitstellen einer integrierten Unterstützung für alle neuen systemeigenen APIs sowie durch zusätzliche Unterstützung für die neuen Steuerelemente und Standarddialogfelder in MFC (Microsoft Foundation Class) und die Dialog-Editoren erreicht. Zusätzlich zu allen systemeigenen Entwicklungsverbesserungen dehnt Visual Studio „Orcas“ die Technologie, die C++-Entwicklern zur Verfügung steht, so aus, dass ihre systemeigenen Komponenten mit verwalteten Microsoft® .NET Framework-Komponenten zusammenarbeiten. Auf diese Weise werden neue Bibliotheken bereitgestellt, die zum Überbrücken der Lücke zwischen systemeigenem und verwaltetem Code dienen. In diesem Artikel werden die neuen Technologien, die in der bevorstehenden Veröffentlichung von Visual Studio „Orcas“ verfügbar sein werden, ausführlich beschrieben.

Vorbereiten von Anwendungen auf Windows Vista
Visual Studio „Orcas“ umfasst alle Header und Bibliotheken, die für die Versionen von Windows 2000 bis Windows Vista erforderlich sind. Dies bietet Entwicklern Zugriff auf die untergeordneten APIs, die direkt vom Betriebssystem verfügbar gemacht werden, und ihre Komponenten für die Verwendung in C/C++-Anwendungen. Abgesehen davon, dass der Zugriff auf APIs der C-Ebene bereitgestellt wird, erweitert Visual Studio „Orcas“ MFC so, dass gegebenenfalls die neuen Windows Vista-APIs verwendet werden. Außerdem enthält es innerhalb des Kontexts der MFC-Bibliothek eine Teilmenge der APIs und macht sie verfügbar.
Die meisten Verbesserungen, die an MFC vorgenommen wurden, betreffen die Benutzeroberfläche. Wenn eine MFC-Anwendung mit Visual Studio „Orcas“ erneut kompiliert wird, wird sie automatisch für Windows Vista überarbeitet. Das heißt, dass Standarddialogfelder verbessert werden, Symbolleisten sich nach den Windows Vista-Themen richten sowie Fensterrahmen und Titelleisten Aero™-Transparenz aufweisen. Diese Überarbeitung geschieht ohne jegliche Codeänderungen. Sie müssen die Anwendung einfach nur neu kompilieren. Selbstverständlich gewinnen Entwickler durch Portieren der MFC-Anwendung in der neuen Version von Visual Studio Zugriff auf die neuen Steuerelemente und Stile, die in Windows Vista verfügbar gemacht werden.
Die aktualisierte MFC führt außerdem alle notwendigen Schritte aus, um die Verwendung der Standarddialogfelder in Windows Vista zu erleichtern. Sehen Sie sich den folgenden MFC-Code an, der mit Visual Studio „Orcas“ kompiliert wird:
    CFileDialog dlgFile(TRUE);
    dlgFile.DoModal();
Abbildung 1 MFC-Standarddateidialogfeld unter Windows Vista (Klicken Sie zum Vergrößern auf das Bild)
Unter Windows Vista wird das neue Standarddateidialogfeld angezeigt, wie in Abbildung 1 dargestellt. Auf früheren Plattformversionen, z. B. Windows 2000, verwendet MFC jedoch einen Fallbackmechanismus, um das alte Standarddateidialogfeld anzuzeigen, wie in Abbildung 2 dargestellt.
Abbildung 2 MFC-Standarddateidialogfeld auf älteren Plattformen (Klicken Sie zum Vergrößern auf das Bild)
Beachten Sie, dass der gleiche Code, kompiliert mit früheren Veröffentlichungen von Visual Studio und MFC, immer das traditionelle Standarddateidialogfeld ergibt, das in Abbildung 2 dargestellt wird, auch unter Windows Vista. Auf Wunsch können Sie das neue MFC-Verhalten außer Kraft setzen, um die Standardeinstellung so festzulegen, dass immer die alten Nicht-Windows Vista-Standarddateidialogfelder angezeigt werden. Dies wird dadurch erreicht, dass dem Konstruktor der CFileDialog-Klasse ein zusätzlicher Parameter übergeben wird, um das bVistaStyle-Kennzeichen auf FALSE zu setzen.
Außerdem ermöglichen die aktualisierten MFC-Klassen Entwicklern, auf die zugrunde liegende COM-Implementierung der Standarddateidialogfelder in Windows Vista zurückzugreifen, um komplexere Aufgaben durchzuführen, z. B. das Anpassen der Standarddateidialogfelder. So verfügt die aktualisierte CFileDialog-Klasse beispielsweise über eine Getter-Methode, die den Zugriff auf die IFileDialogCustomize-Oberfläche bereitstellt, die es Entwicklern ermöglicht, dem Dialogobjekt Steuerelemente hinzuzufügen.

Hinzufügen von Unterstützung für neue Standardsteuerelemente
Unterstützung für die neuen Steuerelemente und Stile, die in Windows Vista verfügbar sind, ermöglichen Entwicklern, großartige, echte Windows Vista-Anwendungen zu erstellen. Mit Visual Studio „Orcas“ wird aber auch Unterstützung für einige Windows XP-Steuerelemente und -Stile hinzugefügt, die in vorherigen Veröffentlichungen von Visual Studio nicht implementiert wurden. Im Folgenden werden die neuen Steuerelemente aufgelistet, die jetzt in Visual Studio „Orcas“ enthalten sind:
Befehlslinksteuerelement Ein Befehlslink, wie in Abbildung 3 dargestellt, ist ein neuer Schaltflächenstil, der in Windows Vista eingeführt wird. Es handelt sich im Wesentlichen um ein Schaltflächensteuerelement mit gesetztem Kennzeichen im BS_COMMANDLINK-Stil. Der Befehlslink ermöglicht verbesserte Benutzeroberflächen mit Schaltflächen, die tatsächlich anzeigen, welche Aktion die Schaltfläche ausführt, einschließlich einer kurzen Beschreibung der Aktion. Dieses Steuerelement wird größtenteils in Windows Vista-Aufgabendialogfeldern verwendet.
Abbildung 3 Befehlslink 
Trennschaltflächen-Steuerelement Ein Trennschaltflächen-Steuerelement, dargestellt in Abbildung 4, ist eine Windows Vista-Schaltfläche, die durch eine raffinierte Bewegung auf der Benutzeroberfläche, durch die ein Dropdownmenü mit mehr Aktionen angezeigt wird, auf eine Standardaktion sowie andere mögliche Aktionen zugreifen kann. Ein Trennschaltflächen-Steuerelement ist im Grunde ein Schaltflächensteuerelement mit gesetztem Kennzeichen im BS_SPLITBUTTON-Stil.
Abbildung 4 Trennschaltfläche 
Netzwerkadressensteuerelement Dieses Steuerelement, dargestellt in Abbildung 5, ist ein einfaches Bearbeitungsfeld in Windows Vista, das die Eingabe überprüft und sie auf eine IPv4-Adresse, eine IPv6-Adresse oder benutzerfreundliche DNS-Namen einschränkt.
Abbildung 5 Netzwerkadresse 
Sys Link-Steuerelement Dieses Windows XP-Steuerelement wurde von früheren Veröffentlichungen von Visual Studio nicht unterstützt. Es stellt eine praktische Möglichkeit bereit, Hypertextlinks in einem Fenster einzubetten, wie in Abbildung 6 dargestellt.
Abbildung 6 Sys Link 
Für jedes der neuen unterstützten Steuerelemente enthält MFC auch Klassen und Benachrichtigungen. Außerdem wurde der Ressourcen-Editor in der IDE aktualisiert, sodass er die neuen MFC-Klassen und Steuerelemente verwendet. Das Toolbox-Fenster zeigt alle neuen Steuerelemente als systemeigene Steuerelemente an, die für den MFC-Dialog-Editor verfügbar sind. Wenn die Steuerelemente in einem MFC-Dialogfeld abgelegt werden, werden sie auf Windows Vista-Hosts korrekt gerendert. Auf älteren Plattformen werden Platzhalter mit einer entsprechenden Nachricht angezeigt, die darauf hinweist, dass das Steuerelement auf Nicht-Windows Vista-Plattformen nicht gerendert werden kann. (Abbildung 7 zeigt ein Vor-Windows Vista-Dialogfeld, während in Abbildung 8 ein aktuelleres Windows Vista-Dialogfeld dargestellt wird. Die Eigenschaftsseiten wurden ebenfalls aktualisiert und zeigen die Stile und Ereignisse an, die für die neuen Steuerelemente verfügbar sind. Schließlich wurden die MFC-Assistenten mit Unterstützung versehen, um Steuerelementklassen und Mitglieder hinzuzufügen.
Abbildung 7 Dialogfeld unter Windows XP 
MFC in Visual Studio „Orcas“ erweitert außerdem die Unterstützung für bereits vorhandene Steuerelemente, die in Windows Vista verbessert wurden. Die folgenden Steuerelemente verfügen über erweiterte Unterstützung: TreeView, MonthCalendar, DateTimePicker, Static, Slider (TrackBar) und Progress. Ferner wurden in Windows Vista viele andere Steuerelemente optimiert, indem erweiterte Stile verwendet werden, um eine abgerundete Benutzeroberfläche und eine umfangreichere Benutzerfunktionalität zu bieten. Die Stile für diese Steuerelemente können direkt durch Senden einer Nachricht zum jeweiligen Steuerelement festgelegt werden. Um zum Beispiel umfassende QuickInfos für TreeView-Steuerelemente zu aktivieren, die ein benutzerdefiniertes Zeichnen des Inhalts mit Symbol und Text bereitstellen, senden Sie eine TVM_SETEXTENDEDSTYLE-Nachricht, um den um TVS_EX_RICHTOOLTIP erweiterten Stil für das Steuerelement festzulegen.
Abbildung 8 Mit Windows Vista-Steuerelementen aktualisiertes Dialogfeld (Klicken Sie zum Vergrößern auf das Bild)
Für Anwendungen, die den Benutzeroberflächenrichtlinien von Windows Vista entsprechen sollen, empfiehlt sich die Nutzung der neuen Steuerelemente, die in Windows Vista verfügbar sind, um eine ansprechende und praktische Benutzeroberfläche zu erstellen.

Andere MFC-Verbesserungen
Neue Windows Vista-Benutzeroberflächenausdrücke, z. B. das Ausblenden der Anwendungsmenüleiste optional als Standard einzustellen, wurden ebenfalls in Visual Studio „Orcas“ berücksichtigt. In diesem speziellen Beispiel wird die Menüleiste nur dann eingeblendet, wenn sie mithilfe der ALT-Taste aktiviert wird. Ansonsten ist die Menüleiste ausgeblendet. Das gleiche Verfahren wird von verschiedenen Microsoft-Anwendungen verwendet, z. B. Internet Explorer® 7.0 unter Windows Vista. Um dieses Verhalten zu aktivieren, muss der Entwickler das passende Kennzeichen für CFrameWnd einstellen, indem CFrameWnd::SetMenuBarVisibility(AFX_MBV_DISPLAYONFOCUS) aufgerufen wird. Aero-Assistenten werden von MFC ebenfalls verfügbar gemacht. Durch Festlegen von m_psh.dwFlags |= PSH_AEROWIZARD im CPropertySheet-Konstruktor können MFC-Assistenten jetzt so aktualisiert werden, dass sie das Aero-Assistentenframework verwenden.
Gleichermaßen wurde der Ressourcen-Editor aktualisiert, um die neuen Benutzeroberflächenrichtlinien von Windows Vista zu unterstützen. Standardmäßig entsprechen neue hinzugefügte Dialogfelder diesen Richtlinien, was Steuerelementplatzierung, Steuerelementgröße und Schriftarten betrifft. Der Ressourcen-Editor stellt außerdem erweiterte Funktionen für das Anzeigen von Symbolen bereit, die in Windows Vista-basierten Anwendungen verwendet werden. Er unterstützt jetzt die Anzeige von 32-Bit-Farbbildern, PNG-Bildern, von großen Symbolen (256 × 56) und PNG-Symbolen (siehe Abbildung 9). Außerdem unterstützt er einen besseren Vorschaumodus für Symboldateien, die mehrere Symbolbilder enthalten.
Abbildung 9 Symbolunterstützung im Ressourcen-Editor (Klicken Sie zum Vergrößern auf das Bild)
Schließlich wurde die Spy++-Anwendung aktualisiert, um neue Nachrichten zu überwachen, die in Windows Vista eingeführt werden. Spy++ bietet außerdem zusätzliche Unterstützung für 64-Bit-Anwendungen in Visual Studio „Orcas“.

Vorbereiten auf die Benutzerkontensteuerung
Eines der bemerkenswertesten neuen Sicherheitsfeatures in Windows Vista ist die Benutzerkontensteuerung (User Account Control, UAC). Mit UAC erhalten Benutzer die niedrigste Berechtigungsebene, und Administratorrechte müssen explizit gewährt werden. Dieses Feature hat sehr wichtige Implikationen. Entwickler müssen sich jetzt unbedingt bewusst sein, wie ihre Anwendung sich verhält, wenn sie unter UAC ausgeführt wird, da die Benutzerkontensteuerung das Standardfeature in Windows Vista ist. Außerdem wird empfohlen, dass Entwickler eine aktive Rolle bei der Optimierung der Desktopsicherheit übernehmen, indem sie die für ihre Anwendung erforderliche Sicherheitsstufe angeben. Visual Studio „Orcas“ unterstützt Entwickler dabei, Anwendungen auf UAC vorzubereiten, indem es ihnen die Arbeit, die von UAC erforderlichen XML-Manifeste manuell zu generieren, abnimmt. Anwendungen, die keine UAC-Manifeste haben und nicht explizit mit Administratorrechten ausgeführt werden, werden in einem Kompatibilitätsvirtualisierungsmodus ausgeführt, bei der alle Schreibvorgänge mit einer globalen Auswirkung, wie in der Registrierung oder in Datenträgerorten von Nicht-Benutzern, zu benutzerspezifischen Orten umgeleitet werden. Beachten Sie jedoch, dass der Kompatibilitätsmodus nur als eine Überbrückungsmaßnahme anzusehen ist, da er zu schwer erkennbaren Fehlern in der Anwendung führen kann. Wir empfehlen, dass alle Anwendungen, die für Windows Vista entworfen werden, auf UAC und ein passendes UAC-Manifest getestet werden.
Das UAC-Manifest kann einen von drei Aufrufmodi enthalten: As-Invoker, Highest-Available und Require-Administrator.
As-Invoker Bei dieser Berechtigungsebene kann die Anwendung mit dem gleichen Token wie ihr übergeordneter Prozess ausgeführt werden. Dies ist die standardmäßige und empfohlene UAC-Einstellung für alle Windows Vista-Anwendungen.
Require-Administrator Diese Berechtigungsebene erfordert, dass die Anwendung mit vollständigen Administratorrechten ausgeführt wird. Nur Mitglieder der Administratorgruppe auf dem lokalen Computer können eine Anwendung mit dieser Einstellung ausführen. Das Aufrufen einer Anwendung auf dieser Berechtigungsebene führt dazu, dass ein UAC-Dialogfeld die Ausführung auf dieser Berechtigungsebene anfordert.
Highest-Available Diese Berechtigungsebene erfordert, dass die Anwendung mit den höchsten Berechtigungen ausgeführt wird, über die der aktuelle Benutzer verfügt. Dies läuft häufig auf die Berechtigung Require-Administrator hinaus, da eine Menge Benutzer als Administrator ausführen.
Wie wird also ein UAC-Manifest generiert? Visual Studio „Orcas“ macht einen neuen Schalter für LINK.EXE verfügbar, der die automatische Generierung von UAC XML-Manifestfragmenten aktiviert. Das Format für den neuen Schalter, /MANIFESTUAC, ist:
/MANIFESTUAC[:{NO|UAC fragment}]
Standardmäßig generiert der Schalter ein Manifest mit der As-Invoker-Berechtigung. Wenn der Schalter auf „Nein“ eingestellt ist, wird kein Manifest generiert und die Anwendung im Kompatibilitätsmodus ausgeführt. Die Angabe von requireAdministrator oder highestAvailable legt die jeweiligen Berechtigungen auf dem generierten UAC-Manifest fest.
Visual Studio „Orcas“ macht außerdem die gleichen Optionen auf den Eigenschaftsseiten eines Projekts verfügbar, wie in Abbildung 10 dargestellt.
Abbildung 10 UAC-Optionen für Visual C++-Projekte (Klicken Sie zum Vergrößern auf das Bild)
Standardmäßig wird ein As-Invoker-UAC-Manifest für alle neuen Anwendungen generiert, die mit Visual Studio „Orcas“ erstellt werden. Bei allen Anwendungen, die von vorherigen Versionen von Visual Studio aktualisiert werden, wird UAC automatisch aktiviert.
Es soll an dieser Stelle auch darauf hingewiesen werden, dass Internet Explorer 7.0 die UAC-Features von Windows Vista verwendet, um einen geschützten Modus mit mehr Sicherheit bereitzustellen. Dieser Modus, der die Standardeinstellung darstellt, führt im Wesentlichen Komponenten innerhalb von Internet Explorer mit weniger Rechten als die Standardbenutzerberechtigungen aus. Dies wird dadurch erreicht, dass Komponenten in einer neu erzeugten Instanz von Internet Explorer gestartet werden, die eine niedrigere Berechtigungsebene hat. Folglich müssen Komponenten, die innerhalb des Internet Explorer 7.0-Kontexts ausführen müssen, z. B. ActiveX®-Steuerelemente, anhand von Internet Explorer 7.0 – Geschützter Modus getestet werden.
Visual Studio „Orcas“ fügt eine neue Option für C++-Projekte hinzu, um das Debuggen für Anwendungen unter Webbrowsern zu ermöglichen. Die Liste verfügbarer Debugger enthält jetzt einen Webbrowserdebugger, von dem Internet Explorer 7.0 – Geschützter Modus berücksichtigt wird und der alle notwendigen Schritte übernimmt, um den neu erstellten niedrigeren Berechtigungsprozess anzufügen.

Zusammenarbeit mit verwaltetem Code
Zusätzlich zum starken Fokus auf systemeigene Tools für C++-Entwickler dehnt Visual Studio „Orcas“ die Unterstützung für Technologien aus, die die Lücke zwischen systemeigenen C++-Komponenten und .NET-Komponenten überbrücken, die mithilfe von verwaltetem Code entwickelt wurden. Seit der Einführung von .NET Framework wurden in immer mehr Anwendungen auf Branchenebene verstärkt verwaltete Komponenten in systemeigene C++-Anwendungen eingearbeitet. Dies erfolgte in Bereichen, für die verwalteter Code geeignet ist und eine Bereicherung darstellt.
Visual Studio „Orcas“ erleichtert die Integration von .NET Komponenten in den vorhandenen und neuen systemeigenen C++-Code. Visual Studio stellt jetzt Bibliotheken bereit, die systemeigene Ausdrücke mit verwaltetem Code verbinden und Sie dabei unterstützen, Code zu erstellen, der die Grenzen des systemeigenen verwalteten Codes überschreitet.

Alles einfacher mithilfe der Marshallingbibliothek
Die wichtigste Anforderung beim Mischen systemeigener und CLR (Common Language Runtime)-Typen ist die Fähigkeit, die Daten über beide Typensysteme zu marshallen. Erfreulicherweise enthält Visual Studio „Orcas“ eine Lösung dafür. Es umfasst eine neue Marshallingbibliothek, durch die die Komplexität beim Erstellen von Code, der Typen zwischen dem systemeigenen und dem CLR-Bereich marshallt, verringert wird. Die Vorgänge der Marshallingbibliothek basieren auf vorhandenen .NET Framework-Routinen, verringern jedoch die Komplexität der Arbeit mit diesen Klassen, indem sie Marshallingroutinen als Mitglieder einer erweiterbaren Vorlagenbibliothek verfügbar machen.
Die neue Marshallingbibliothek verfügt über integrierte Unterstützung für all die verschiedenen allgemeinen Zeichenfolgentypen, die von C++-Anwendungen verwendet werden, z. B. ATL CString, BSTR, CComBSTR, char *, wchar *, std::string, std::wstring und System::String^. Hinzu kommt, dass Entwickler den unterstützten Standards mehr Konvertierungen hinzufügen können. Hier ist ein einfaches Beispiel für das Verwenden der Marshallingbibliothek, um System::String in char * zu konvertieren:
#include <msclr/marshal.h>

void myfunc (String^ s)
{
    msclr::interop::marshal_context ctx;
    char *s2 = ctx.marshal_as<char*> (s);
    //...
}

Verwenden von STL/CLR für CLR-Typen
Die Container-Iterator-Algorithmusstruktur der Standardvorlagenbibliothek (Standard Template Library, STL) hat die C++-Entwicklung vereinfacht und ist jetzt ein Muster, an das sich viele C++-Entwickler gewöhnt haben. Visual Studio „Orcas“ führt die gleichen Ausdrücke, die STL für systemeigene Typen ermöglicht, mithilfe von STL/CLR für CLR-Typen ein. Diese neue Funktion birgt das Potenzial, die Produktivität von C++-Entwicklern erheblich zu steigern, indem sie die Verwendung der gleichen Ausdrücke sowohl im systemeigenen als auch im verwalteten Bereich ermöglicht. Außerdem erleichtert dieses Feature den Datenaustausch zwischen STL-Containern und .NET-Sammlungen.
STL/CLR stellt die gleichen Container für CLR-Typen bereit, die STL für systemeigene Typen bereitstellt. Die neuen Container sind Teil des client-Namespace. STL/CLR behält zudem die gleiche algorithmische Komplexität wie STL bei. STL/CLR-Container können bereinigte CLR-Verweistypen und Werttypen beinhalten sowie CLR- und systemeigene integrierte Typen. Sie können keine rein systemeigenen Typen oder Zeiger auf systemeigene Typen beinhalten.
STL/CLR macht außerdem Iteratoren verfügbar, die in Verbindung mit den Containern funktionieren. STL/CLR-Iteratoren behalten die gleiche Hierarchie bei wie die von STL-Iteratoren, und der Zugriff auf die STL/CLR-Iteratoren erfolgt in genau derselben Weise. STL/CLR macht zudem den gleichen Satz von Algorithmen verfügbar wie STL. Die Algorithmen können in STL/CLR- und STL-Containern eingesetzt werden. Das folgende Beispiel zeigt STL/CLR-Container und Iteratoren in Aktion:
#include <cliext/hash_map>

void myfunc ()
{
    cliext::hash_map<Int32, String^> m;
    m.insert (cliext::make_pair(5, L”five”));

    cliext::hash_map<Int32, String^>::iterator i = m.find(5);
    Console::WriteLine(“map[{0}] == {1}”, i->first, i->second);
}

Code jetzt noch schneller erstellen
Des Weiteren hat sich das Entwickeln von C++-Code, der auf CLR abzielt, insofern verbessert, als inkrementelle Builds bedeutend schneller ablaufen. Die Notwendigkeit, Abhängigkeiten neu aufzubauen, auch wenn an Kernkomponenten nur Implementierungsänderungen und keine Schnittstellenänderungen vorgenommen wurden, stellte schon immer einen Schwachpunkt in der Entwicklung großer CLR-Anwendungen dar, die C++-Komponenten enthalten. Das lag an CLR-Assemblys, von denen sowohl die Metadaten als auch die Implementierung einer Komponente in eine Binärdatei gepackt wurden. Demzufolge mussten große C++-Projekte, die von CLR-Assemblys abhängen, wieder aufgebaut werden, falls sich ein beliebiger Teil der CLR-Assembly änderte.
Die bevorstehende Veröffentlichung von Visual Studio fügt ein neues Tool hinzu, das eine auf Metadaten beschränkte Assembly erstellt, von der die Oberfläche erfasst und nur die abhängigen C++-Projekte wiederaufgebaut werden, falls sich die Schnittstellenassembly ändert. Durch Änderungen an der Implementierung einer Assembly wird kein Wiederaufbau der abhängigen Assemblys ausgelöst. Dadurch können die Buildzeiten im inkrementellen Buildszenario deutlich verringert werden, was die Entwicklerproduktivität optimiert.
Da ich gerade den Builddurchsatz angesprochen habe: Was mir an Visual Studio „Orcas“ am meisten zusagt, ist die Fähigkeit, Quelldateien parallel zu kompilieren. Dies funktioniert sowohl für systemeigenen als auch verwalteten Code. CL.EXE stellt einen neuen Schalter bereit, /MP, um dieses Verhalten zu ermöglichen. Die Syntax für den neuen Schalter ist folgendermaßen:
/MP[n] use up to ‘n’ processes for compilation
Hierbei gibt n grundsätzlich die Anzahl der Prozessoren an, die verwendet werden sollen. Wenn die Anzahl der Prozessoren nicht angegeben ist, verwendet der Compiler die Anzahl logischer Prozessoren, die auf dem Computer verfügbar sind. Wenn eine Zahl angegeben ist, werden genau n Prozesse für die Kompilierung erzeugt.
Das Feature für die parallele Kompilierung funktioniert so, dass verschiedene Übersetzungseinheiten in verschiedenen Prozessen kompiliert werden. Eine einzelne Übersetzungseinheit kann nicht über mehrere Prozesse kompiliert werden. Bedenken Sie zum Beispiel die Ergebnisse des folgenden Compileraufrufs bei Ausführung auf einem Vierprozessorcomputer:
CL /c /MP a.cpp b.cpp c.cpp d.cpp e.cpp f.cpp
Der Compiler kompiliert letzten Endes vier Übersetzungseinheiten, und parallel dazu werden neue Übersetzungseinheiten kompiliert, sobald einer der vier Prozessoren freigegeben wird.
Sehen Sie sich jetzt die Ergebnisse des folgenden Compileraufrufs an, der auf einem Dualprozessorcomputer ausgeführt wird:
CL /c /MP a.cpp
Der Compiler führt eine serielle Kompilierung der einzelnen Übersetzungseinheit durch, die er empfangen hat, da er keine parallele Kompilierung innerhalb einer Übersetzungseinheit durchführt.

Schlussbemerkung
Die bevorstehende Veröffentlichung von Visual Studio „Orcas“ stellt deutlich verbesserte Tools für C++-Entwickler bereit, die die neuen Features und Funktionen von Windows Vista ausnutzen möchten. In dieser Veröffentlichung werden Win32®-Entwicklern Tausende von neuen Windows Vista-APIs zur Verfügung gestellt. MFC wurde außerdem so verbessert, dass viele Windows Vista-Features sofort von MFC-Entwicklern eingesetzt werden können. Die IDE erweitert die Ressourcen-Editoren, um neue Windows Vista-Steuerelemente verfügbar zu machen. Zudem wurde Unterstützung für das Erstellen von UAC-bewussten Anwendungen hinzugefügt.
Darüber hinaus bietet Visual Studio „Orcas“ Entwicklern, die die Lücke zwischen dem systemeigenen C++-Code und der CLR überbrücken müssen, Verbesserungen an. Dies wird mit neuen Bibliotheken und Tools erzielt, die zur Steigerung der Entwicklerproduktivität beitragen. Weiterhin enthält die neue Version von Visual Studio äußerst praktische neue Features wie die parallele Kompilierung, um die Entwicklerarbeit zu optimieren.

Tarek Madkour ist leitender Programmmanager im Visual C++-Team von Microsoft. Er hat in den vergangenen sechs Jahren an verschiedenen Bereichen der Visual C++-IDE und des Compilers gearbeitet.

Page view tracker