18

I recently switched to Visual Studio 2010 and for Intellisense not to take half a minute to show up when using boost libraries, Microsoft's suggestion seems to use precompiled headers.

Except that I never used them before (except when forced to by Ugly ATL Wizards (TM)), so I searched around to figure out how they work.

Basically, the Big Centralized stdafx.h approach seems plain wrong. I never want to include (even cheaply) a whole bunch of header files in all my sources. Since I don't use windows libraries (I make C++/CLI higher level wrappers, then use .NET for talking to the outside world), I don't have "a whole truckload of non-changing enormous headers". Just boost and standard library headers scattered around.

There is an interesting approach to this problem, but I can't quite figure out how to make this work. It seems that each source file must be compiled twice (please correct me if I'm wrong): once with /Yc and once with /Yu. This adds burden on the developper which must manually tweak the build system.

I was hoping to find some "automatically generate one precompiled header for each source file" trick, or at least some "best practices", but most people seem happy with including the world into stdafx.h.

What are the options available to me to use precompiled headers on a per source file basis ? I don't really care about build times (as long as they don't skyrocket), I just want intellisense to work fast.

Alexandre C.
  • 55,948
  • 11
  • 128
  • 197
  • 2
    Now _that_ is a good question. I usually end up abandoning PCH and resorting to mingw-gcc with ccache. This is always much faster anyway – sehe May 07 '11 at 19:14
  • 9
    IntelliSense for C++ sucks; in VS2010 it just sucks a little less than it used to. As for precompiled headers, fighting the system is more trouble than it's worth; just go with the flow. – Luke May 07 '11 at 19:14
  • 3
    Just a question: Your problem basically seems to be that Intellisense is slow for Boost in VS2010? Could Visual Assist X be an option for you? – Bart May 07 '11 at 19:15
  • @Bart: Why not. I'll run the trial. I was hoping for some "built in" solution. Does it also provide Intellisense for C++/CLI (that would be a plus) ? – Alexandre C. May 07 '11 at 19:20
  • @Alexandre: I don't have a built-in solution, so I just made it a comment. About C++/CLI, I honestly don't know, but I guess it should. Good luck. Hope this works for you. – Bart May 07 '11 at 19:26
  • PCH's are a horrible hackish 90's solution to an 80's problem. But it'll probably be another decade or three before any compiler vendors get around to doing anything like you suggest. It would be nice though. – jalf May 07 '11 at 20:33
  • VC++ 6.0 (the last good C++ IDE MS produced), used to have an "automatic use of PCHs" project option which didn't require that stdafx.h cr*p. Is that still there? Probably not.... –  May 07 '11 at 21:19
  • @unapersson: it has been removed because it caused too many systematic recompilation of the header file. – Alexandre C. May 07 '11 at 22:03
  • @Bart: after weighing the options, it seems that Visual Assist X is the solution I'm after (and I'm a bit angry having to *pay* for patching an *expensive* product). Could you please post it as an answer ? I chose **not** to use PCH at all, since I now understand how sh*tty they actually are and how they are far to solve any problem (except some build times for some projects, but it is not my problem for now). – Alexandre C. May 08 '11 at 14:42
  • @Alexandre: Done. I feel your pain. Went with VA several years back because of similar experiences and it worked for me. The best of the worst options I guess. – Bart May 08 '11 at 14:47
  • i think the title should mention intellisense instead of precompiled headers. – Agnel Kurian May 08 '11 at 15:16

4 Answers4

9

For starters, you are reading the article wrong. Every file is NOT compiled twice. The file stdafx.cpp gets compiled once with /Yc (c, for create) before anything else and then every other file in your project gets compiled once with /Yu (u, for use) and imports the result of the previously created saved state from stdafx.cpp.

Secondly, the article is 7 years old and is talking about VC++ 6, so you should start off distrusting it. But even assuming the information in it still applies to VC++ 2008 or 2010, it seems like bad advice. The approach it recommends using /pragma hdrstop is solution looking for a problem. If you have headers that contain things you don't want in every file, then they simply shouldn't go in your pre-compiled header.

Alan
  • 4,897
  • 2
  • 24
  • 17
  • If I read your last sentence correctly, I shouldn't be using precompiled headers at all. – Alexandre C. May 08 '11 at 06:53
  • 1
    You shouldn't be using pre-compiled headers for headers that create symbols that would be dangerous to expose everywhere. They are instead for headers that are safe and self-contained like boost and stl or for things that you actually do need to include everywhere like windows.h. – Alan May 09 '11 at 06:35
5

Your problem basically seems to be that Intellisense is slow for Boost in VS2010? I don't have a direct solution for this problem, but could Visual Assist X be an option for you? I have used it in various versions of Visual Studio now and with great pleasure. Not a direct solution, but it might work for you.

Bart
  • 19,692
  • 7
  • 68
  • 77
  • Its worth to note that Visual Assist won't significantly improve auto-complete for boost, as boost is a rather complex library, and auto-complete tools dont seem to work that well with it. Visual Assist is however an awesome tool and I can't imagine working without it, so you should check it out anyway. Besides that, I can't seem to understand the link between Intellisense and precompiled headers, does VS get intellisense from precompiled headers?? – Grim May 08 '11 at 15:06
  • I am accepting this one since it answers the question (about intellisense, title edited btw). I prefer an answer which solves problems (albeit non freely) that the (good) ones which describes a 15 year old pain in the ass feature. Thank you everyone. – Alexandre C. May 08 '11 at 17:34
4

Precompiled headers aren't too bad if you use them properly.

Don't use them as a replacement for proper and precise #includes, but as a way to speed things up. Achieve this by making the precompiled header do nothing in release builds, only speeding stuff up in debug.

snemarch
  • 4,958
  • 26
  • 38
  • 1
    this seems reasonable. This also means that they shouldn't be used except when you have a lot of huge headers in almost all your source files (which is what I try hard to avoid). – Alexandre C. May 08 '11 at 14:38
3

You are wrong, each file is only compiled once. You have one .cpp file that is compiled with /Yc and the rest are compiled with /Yu. The file with /Yc, which is stdafx.cpp by default, contains one line, #include "myMainHeader.h" (changed the name from the default) All other .cpp files must start with #include "myMainHeader.h" When your /Yc file is compiled, the entire internal state of the compiler is saved. That file is loaded when each of your other files is compiled. That is why you must start with including the PCH, so that the /Yu option doesn't change the result of compilation, only the time. Xcode does not make this requirement and will use a PCH regardless of if your .cpp file starts with the right include directive. I have used libraries that relied on this and could not be built without PCH.

IronMensan
  • 6,761
  • 1
  • 26
  • 35
  • 1
    @Alexandre the linked article talks about using the /FI option or #pragma hdrstop instead of using the #include directive in each file. I wouldn't recommend that for the sake of compatibility. – IronMensan May 08 '11 at 01:01
  • okay, sorry for being a bit harsh, but it seems that I did not understand the fact that one extra file was needed to actually generate the PCH. Now that I got this, that guy's solution seems terrible for my purpose: it is intended to be activated when building the release product and deactivated when debugging. – Alexandre C. May 08 '11 at 14:37