wie in meinem letzten Posting beschrieben, hat Microsoft mit dem Service Pack 1 endlich wieder einen “richtigen” HelpViewer bereitgestellt.

Das war dann auch der einzige Grund, warum ich das Service Package installiert habe.

Leider scheint mir der neue HelpViewer noch nicht optiomal in Visual Studio eingebunden, weshalb ich hier die Schritte zu einer sinnvollen Konfiguration dokumentieren möchte.

Zunächst muss die Hilfe so konfiguriert werden, dass die “lokale Hilfe” verwendet wird. Bleibt man bei der “Onlinehilfe”, ändert sich am Verhalten nichts, d.h. wenn Hilfe angefordert wird, wird der Browser gestartet und lädt eine mehr oder weniger passende Seite von der msdn-Website.

Um die lokale Hilfe auszuwählen, muss man den “Hilfebibliotheks-Manager” starten, z.B. über den Eintrag “Hilfeeinstellungen verwalten” im Menü Hilfe.

Dann klickt man auf “Onlinehilfe oder lokale Hilfe auswählen” und wählt anschließend “Ich möchte die lokale Hilfe verwenden”.

Lokale Hilfe auswählen

Danach ist man aber noch nicht viel weiter, da (zumindest bei meiner Installation) noch keine lokalen Inhalte für die Hilfe vorliegen. Diese müssen nun durch Klick auf “Inhalt von Online-Speicherort installieren” lokal installiert werden.
Der Hilfebibliotheksmanager lädt dann eine Liste mit abrufbaren Inhalten und zeigt diese in einer baumartigen Sicht an. Dort klickt man nun für jedes gewünschte Paket auf den Link ‘Hinzufügen’.

In folgendem Beispiel wurde als letztes die Hilfe für “Visual C#” ausgewählt:

Auswahl einzelner Hilfepakete

Die Aktualisierung der geschätzten Downloadgröße nach der Aus- oder Abwahl eines Paketes dauert einen Moment. Nach einem Klick auf “Aktualisieren” werden die Hilfeinhalten dann geladen und lokal installiert.

Nach dem der äußerst langsamen Download (ca. 200 KBit/s) wollte ich dann ein Gefühl für die Qualität der Suche bekommen.

Die Eingabe des Suchbegriffes std::vector brachte als Ergebnisse “Implementing an STL based collection”, “checked_array_iterator Class” usw. Kein einziger der zwanzig Treffer hatte etwas mit der gewünschten Klasse, welche eine essentielle Klasse der C++ Standardbibliothek ist, zu tun. Wenig überraschend wurde das Ergebnis nicht besser, wenn man den Namensraum std:: wegläßt. Das ist ein sehr schwaches Ergebnis und disqualifiziert den HelpViewer als direktes Frontend für Suchen in der Hilfe.

Eine weitere wichtige Frage besteht darin, ob der HelpViewer effizient Hilfe für Begriffe aus einem Quelltext anzeigt. Immerhin kennt die IDE den genauen Typ jedes Tokens und hat damit alle Informationen, die benötigt werden, um eine eindeutige und korrekte Hilfe anzuzeigen.
Leider wird diese Hoffnung nicht erfüllt, wie man an diesem kleinen Beispiel sieht:

if (getElements().size() != rhs->getElements().size())

getElements() liefert eine Instantiierung von std::map zurück. Die IDE “weiß” das auch, wie man an dem tooltip für das token ’size’ sieht oder auch den Möglichkeiten, die die “member completion” anbietet.

Der HelpViewer zeigt allerdings die Seite für hash_set::size() an, was nicht korrekt ist. Die Hilfe für Schlüsselwörter, die eindeutig sind (z.B. auto_ptr) wird korrekt angezeigt, was aber auch keine große Leistung ist.

Insgesamt bleibt ein enttäuschender Eindruck. Zumindest für C++-Entwickler die viel mit der C++ Standard-Bibliothek arbeiten, stellt der HelpViewer keine Verbesserung dar.

Viele Grüße,
Andreas

Technorati Tags: Visual Studio 2010, SP1, HelpViewer

in einem früheren Posting habe ich mein Unverständnis ausgedrückt, dass Microsoft die Hilfe-Funktion in Visual Studio 2010 quasi abgeschafft hat. Auch in Zeiten des Internet und der Suchmaschinen ist eine gute Hilfe-Funktion wichtig.

Nachdem diese Klage ja sehr verbreitet  war, scheint Microsoft ein Einsehen zu haben, und bringt mit dem Service Pack (SP) 1 für Visual Studio 2010 wieder eine richtige Hilfe-Funktion.
Ich bin sicher, dass der lokale Help-Viewer eine Verbesserung gegenüber der aktuellen Situation darstellt.

An der fehlenden Intellisense-Funktion für managed C++/CLI (managed C++), die ja auch viele Benutzer vermissen, scheint sich nichts getan zu haben. Microsoft scheint hier auch einen der Nachteile einer ‘buy’-Lösung zu erfahren: die fehlende Möglichkeit der individuellen Anpassung. Vermutlich lässt sich der hinzugekaufte Compiler der Edison Design Group, der ja in Visual Studio 2010 für die Bereitstellung der Intellisense-Fetaures in C++ verwendet wird, nicht ohne weiteres so erweitern, dass er mit den Spracherweiterungen von C++/CLI vernünftig umgeht.

Auf der anderen Seite muss man sagen, dass der Intellisense-Support für Standard C++ in Visual Studio 2010 viel besser ist als in älteren Versionen von Visual Studio und die Produktivität spürbar steigert. Insbesondere, dass Fehler direkt beim Tippen angezeigt werden, ist eine große Hilfe (man könnte auch sagen, dass dieses Feature langsam überfällig war).

Viele Grüße,
Andreas

Technorati Tags: Visual Studio 2010

wer sich für C++ interessiert und seinen Horizont erweitern will sollte mal auf die Seite “More C++ Idioms” auf wikibooks.org anschauen.

Dabei kann man nicht nur bekannte C++ Pattern wie Empty Base Class Optimization oder Copy-and-swap wiederholen sondern sich auch interessante neue Ideen aneignen, wie z.B. Safe bool.

Aber Achtung: im Gegensatz zu der Angabe auf der Seite würde ich die Anforderungen an die Leser nicht als “intermediate” sondern als “advanced” einstufen.

Viele Grüße,
Andreas

Technorati Tags: C++, Pattern

vor einiger Zeit bin ich zu dem Schluss gekommen, meine Entwicklungsumgebung auf Basis von Windows 7 und Visual Studio 2010 neu aufzusetzen. Nach der Konvertierung der C++ Projekte wurde in einer Solution mit C# und C++ Projekten folgende Warnung ausgegeben:

Warnung    2    Auf das Projekt “xxx” kann nicht verwiesen werden.  Das Projekt, auf das verwiesen wird, hat eine höhere Frameworkversion (”4.0″) als Ziel.

In der ursprünglichen Solution war für alle Projekt das .NET Framework 2.0 als Targetversion eingetragen. Das war aus gutem Grund so, da die erstellte Anwendung für den Download über das Internet bereit gestellt wird und auf möglichst vielen Computern ohne weitere Vorbereitungen eingesetzt werden soll.

Eine Erklärung für die implizite Erhöhung der Targetversion für Managed C++ Projekte finden sich in diesem Blog-Eintrag mit einem “Visual Studio 2010 C++ Project Upgrade Guide”:

After conversion, managed C++ projects will target the 4.0 Framework by default.  The reason behind this design is that the VS2010 compiler cannot target Framework 2.0, 3.0 or 3.5. The VS2008 compiler must be used to target 2.0, 3.0 or 3.5. To make the converted C++ application build out of box, we decided to move the TargetFrameWorkVersion to 4.0 by default for C++ applications.

Oops! Mit Visual Studio 2010 können keine Managed C++ Anwendungen für .NET Framework Versionen < 4.0 erstellt werden!

Dagegen hilft nur eines:

The VS2008 compiler must be used to target 2.0, 3.0 or 3.5.

D.h. man ist gezwungen, Visual C++ 2008 zusätzlich zu installieren, wenn man Managed C++ Komponenten erstellen will, die .NET Frameworks < 4.0 als Target haben. Die Änderung der Zielversion geht noch nicht mal in der IDE sondern nur durch Änderung der Projektdateien in einem Editor.

Ich betrachte das als erhebliche Einschränkung, da man in diesem Fall Visual Studio 2008 zusätzlich installieren (und ggf. kaufen) muss, sondern dann auch die schönen neuen C++ Features des Compilers nicht mehr nutzen kann.

Generell habe ich den Eindruck, dass Microsoft sich mit Visual Studio 2010 etwas übernommen hat, und irgendwann einfach die Produktfreigabe beschlossen hat, obwohl es noch viele Probleme und Einschränkungen gab (z.B. wie im obigen Blog-Eintrag beschrieben, oder das Fehlen von Intellisense für Managed C++ oder die unscharfe Erscheinung der Default-Fonts auf manchen Betriebsystemen oder der erhöhte Speicherbedarf  oder das aus nicht nachvollziehbaren Gründen umgestellte Hilfesystem, das jetzt eigentlich unbrauchbar ist.).

Auf der Haben-Seite steht für mich ganz klar der neu implementierte Support für Intellisense (bei native C++ Projekten). Das funktioniert jetzt viel besser als mit Visual C++ und verbessert die Produktivität spürbar.

Viele Grüße,
Andreas

Technorati Tags: Visual C++

Microsoft hat mit der Einführung des .NET-Frameworks auch C++-Erweiterungen (C++/CLI) definiert, mit denen vorhandener C++ source code für .NET-Anwendungen verfügbar gemacht werden kann.

Die Intention dabei war die Steigerung der Akzeptanz des .NET-Frameworks, da es relativ einfach gemacht wird, bereits vorhandenen C++ code in .NET-Anwendungen zu integrieren. Meiner persönlichen Erfahrung nach geht das sehr gut, d.h. es ist ziemlich einfach vorhanden C++ code mit C++/CLI .NET-tauglich zu machen und die entstandenen Assemblys haben keine nennenswerten Einschränkungen (abgesehen davon, dass sie nur für die Plattform geeignet sind, für die der native code kompiliert wurde).

Der übliche Weg besteht darin eine neue Assembly zu erstellen, die C++/CLI Klassen (und ggf. native Klassen) enthält. Diese Klassen rufen dann den eigentlichen legacy code, typischerweise in bereits vorhandenen Libraries/DLLs.

Folgende Frage stellt sich bei der Erstellung eines Managed C++ Wrappers um vorhanden C++ code schnell:

Wie kann ich innerhalb des .NET-Wrappers native Datenstrukturen zwischen managed Klassen austauschen?

Dies ist grundsätzlich nicht ohne weiteres möglich, da in der öffentlichen Schnittstelle nur CLR-kompatible Datentypen verwendet werden dürfen (ansonsten könnten nicht alle Elemente der Schnittstelle von anderen .NET kompatiblen Komponenten konsumiert werden).

Es ist allerdings möglich, private Methoden zu definieren, die nicht CLR-konforme Datentypen konsumieren oder zurückgeben dürfen. Damit solche Methoden von anderen Klassen in der C++/CLI Wrapper-Assembly gerufen werden dürfen, müsste man alle diese Klassen als friend definieren, was eine etwas unbefriedigende Lösung ist.

Diese Überlegung führt aber zur optimalen Lösung: die Deklaration der entsprechenden Methoden als public private. public private ist in C++/CLI die Entsprechung zu internal in C# und bedeutet “sichtbar innerhalb der Assembly”.
Da die entsprechenden Methoden nur von den C++-Klassen innerhalb der Wrapper-Assembly gerufen werden, gibt es keinen Grund sie zu verbieten (was der Compiler dann auch nicht macht).

Viele Grüße,
Andreas

Technorati Tags: .NET, Managed C++

in C++ gibt es ja das Resource Aquisition Is Initialization (RAII) pattern. Der Kern dieses Patterns besteht darin, dass ein Objekt bereits bei der Konstruktion die Ownership für eine Resource übernimmt und diese Resource bei seiner Zerstörung wieder frei gibt. Man wendet dieses pattern an, um Resourcen wie allokierten Speicher oder file handles sicher freizugeben. Dabei mancht man sich zu nutze, dass in C++ der Destruktor eines Objektes deterministisch aufgerufen wird, z. B. auch im Falle eine exception.

Dieses pattern ist sehr wichtig, um zuverlässige und robuste Software in C++ zu schreiben und ich nutze es regelmäßig. Nun hatte ich vor einiger Zeit in einem der Unittests in der Software, die ich für mein Unternehmen EmPowerTec schreibe, einen seltsamen Fehler in einem Unittest. Nach einer längeren Debugging-Session sah es so aus, als würden die Destruktoren für Objekte die in einer Methode auf dem Stack angelegt waren, beim Verlassen der Methode nicht mehr gerufen. Ein solches Verhalten führt mit Sicherheit zu Fehlern, wenn das RAII Pattern genutzt wird. Zunächst war ich darüber verblüfft, da ich mir nicht vorstellen konnte, dass ein derartig fundamentales Verhalten vom Microsoft C++ Compiler nicht richtig implementiert war. Tatsächlich war das aber der Fall, wie in folgendem Knowledge Base Eintrag beschrieben:

http://social.msdn.microsoft.com/forums/en-US/vclanguage/thread/8324a598-ad05-40e1-a271-6f64ce3b6008

Wie man dem Thread entnehmen kann, tritt das Problem auf, wenn man von einer C++/CLI Library eine native C++ library aufruft und diese mit inkompatiblen Einstellungen für das Exception handling übersetzt hat.

Und die Moral von der Geschicht,
Trau’ keinem Compiler nicht,

Unittests sollst Du machen,
Sonst hast Du nichts zu lachen

Viele Grüße,
Andreas

Technorati Tags: Microsoft Visual C++, RAII