In this part of the “Projects in Visual C++ 2010” mini series another important aspect of C++ programming is explain: precompiled headers. Precompiled headers (or precompiled header files) in many cases significantly reduce the time needed to compile a project.

Here at work I have a C++ project with about 50 .cpp files in it. The project uses the Qt library and all files only include the absolute minimum of header files required. Without precompiled headers, compiling the project takes about 56 seconds. With precompiled headers, the compile time goes down to about 7 seconds. That’s eight times faster.

Related Articles:

• Projects in Visual C++ 2010 – Part 1: Creating a DLL project

• Projects in Visual C++ 2010 – Part 2: Project Dependencies

Read more →

Everyone who has ever created and managed a C++ project in Visual Studio knows that there are hundreds of compiler switches and options to choose from. While setting the desired values for one project may be ok, it’s quite time-consuming and error-prone to do this for multiple projects. I’m currently working with a solution containing about 30 or so projects that share most of their project settings. I always wished there was a way to sync or share these common settings among the projects in the solution. Fortunately, there is: property sheets. They’re a bit hidden though, so I’ll explain how to use them in this article.

Note: This only applies to C++ and C++/CLI projects. .NET projects (C# and Visual Basic) don’t have that many options to be tweaked and (therefore?) can’t have shared settings.

Note 2: This article describes property sheets as they appear in Visual Studio 2010. They may work slightly different in other versions of Visual Studio.

Read more →

Manchmal nervt Programmieren einfach. Da hat man folgende Zeile in C++ (bääääh):

PathOption test = mQ1Settings->WorldDir;

Versucht man diese mit Visual C++ 2010 zu kompilieren, stürtzt der Compiler ab. WTF?

Ok, kann ja mal passieren. Also danach gegoogelt. Zu dem Problem gibt es auch schon einen Bug-Report bei Microsoft. Allerdings meint der Verantwortliche dazu:

I can confirm that this is a bug in our compiler. This crash is unfortunate, but … blablabla …, we believe that this is not critical to fix in the next release.

Ein Compiler-Fehler ist “not critical”???

Nach diesem Statement folgt dann noch:

We will keep this bug in our database and will reconsider it for future releases.

Aja. Deshalb hat der Bug-Report auch den Status “Geschlossenes als nicht lösbar”. Klingt natürlich total danach, dass man sich damit später noch mal befasst.

Na gut. Zum Glück gibt es ja die Möglichkeit, seinen eigenen Senf zu dem Bug-Report abzugeben. Dafür muss man sich zwar registrieren, aber einen Account bei Microsoft’s Bug-Tracker könnte man ja evtl. häufiger gebrauchen

Also schnell auf “Registrieren” geklickt, irgendwelchen AGBs zugestimmt, und dann das:

WTF? Das ganze noch zwei Mal probiert, mit dem gleichen Ergebnis.

Schon sichtlich genervt, gebe ich der Sache noch eine Chance. Zum Glück kann man ja Microsoft “hierüber einen Fehlerbericht” senden. Also klicke ich auf den Link, mit der Erwartung, dass Microsoft jetzt über diesen Fehler benachrichtigt wurde. Aber Pustekuchen!

Ich lande in einem MSDN-Forum (mit dem viel-sagendenden Namen “MSDN, TechNet, and Expression Profile and Recognition System Discussions”).

Jetzt reicht’s mir. Wie oft will mich Microsoft denn noch auf eine andere Seite weiterleiten?? Ich wette, ich kann mich auch im MSDN-Forum nicht registrieren (hab ich allerdings nicht probiert). Dann darf ich am Ende einen Bug-Report (Forum) über einen Bug-Report (Microsoft’s Bug-Tracker) über einen Bug-Report (C++ Compiler) schreiben? Nein Danke!

Und dabei wollte ich doch einfach nur programmieren. Danke, Microsoft!

Update (22.6.2011): Das Problem besteht immer noch. Und ich habe inzwischen das Forum ausprobiert; wie erwartet tritt der Fehler hier auch auf, d.h. ich kann nicht mal einen Fehlerbericht im Forum schreiben. Das ist echt ne schwache Leistung, Microsoft!