The Software Purist |

TAG | Visual C++ .Net

Dec/09

5

Visual Studio Helpers: VS Plugins Edition

I wanted to write in here with some of my favorite Visual Studio Tools, that I find useful in my every day work.

VSFileFinder

VSFileFinder has a very simple concept: You have a lot of files, but it takes a while to navigate for which project they’re in.  Not so with VSFileFinder.  This helpful tool allows you to type a few letters of a file or even use wildcards in your search and helps you find the files you’re looking for.  The premise is simple, but this tool definitely meshes well with my workflow.

CppDoc Comment Maker

CppDoc comment maker gives you an easy to fill out template for generating a new comment that conforms to the JavaDoc standard.  Again, there isn’t much to say here, other than it streamlines the workflow making this process easier.  I will admit, I haven’t used this one as much lately, since I discovered Visual Assist X (below).

Visual Assist X

Visual Assist X is really a lifesaver, especially if you do a lot of C++ work.  It has an incredible amount of features, including syntax highlighting, improved intellisense and refactoring.  The syntax highlighting in Visual Assist X is more intuitive and easier to follow than the default in Visual Studio.  The intellisense performs better, and actually seems to do more than Visual Studio Intellisense typically does.  I find it’s less prone to getting “confused”.  Finally, the refactoring is a godsend.  Refactoring tools in C++ are almost non-existent.  So, while Visual Assist X doesn’t provide as many refactoring capabilities as you get in Java IDEs, it does a good job.  Furthermore, you can edit and configure the snippets, to further customize your refactoring.  For this reason, I actually don’t use CppDoc Comment Maker so much, because I can use Visual Assist X to generate a CppDoc-style comment once I edit the template.  At a later date, I plan to share some of my useful Visual Assist X snippets that I use.

· · · ·

Nov/09

27

Strange Bug in Visual Studio 2008

So, I’ve been doing some coding and I ran into a peculiar bug. It stumped me for about an hour before I realized what was going on.

The long story short is I’ve been developing some new code that I’m playing around with. I have a habit of making template files and using these to create new files to save time. Every once and a while I miss a replace. I should automate this process a bit further and probably will in the future. Anyway, I wrote some code and I had a few linker errors from one class, let’s call it DoSomethingUseful. I peeked and prodded and noticed that I accidentally didn’t replace the header guards correctly, so I had four template files with the same header guard. At first I was like, “ah ha! I found the culprit.” I confidently rebuilt. Yet, on reflection, if you think about the fact that it is a linker error a bit more, you’ll realize that this logically could not be the culprit.

Sure enough, the build fails again. I was racking my brain. I took a look at this class. One thing I try to do when I have weird linker errors is to start removing code. I commented out the code that used it and it built; no big surprise. I then moved the code for this class from the DoSomethingUseful.cpp to the DoSomethingUseful.h file, as my next test. Sure enough, this built successfully also. I was stumped for a while, and was almost ready to leave the code in the header and move on. Then, the problem hit me like a ton of bricks…

I had a parallel folder hierachy where there was another class with the same name, in a different namespace, yet in the same project. Note that there is nothing morally wrong with doing this, and I typically have done this in the past. Namespaces are supposed to protect you against name clashes, so it’s perfectly reasonable to reuse a name as long as it’s in a different namespace. As a test, I renamed the class and sure enough, it built. After this, I did a little bit of searching, and this is not a completely unknown problem in Visual Studio 2008. So, word of caution for Visual Studio users: Two cpp files with the same name, even in different folders, but in the same project, can be problematic due to this compiler bug.

I wonder if this has been fixed for Visual Studio 2010.

· · · · · · · · ·

Nov/09

23

Visual C++ .Net Tips and Tricks

In this installment, I wanted to go through some tips and tricks I’ve discovered during my typical development process using Visual C++ .Net.  Hopefully, you will find they ease your development process.  Some of them may seem obvious, others, perhaps not as much.  These tips will be particularly applicable to Visual Studio 2005 and 2008, but many have a reach past these two versions.

Visual Studio Running Slow

This  can be due to a variety of reasons.  Certainly, hard drive speed is one of the main factors.  Visual Studio intellisense is a hog when it comes to hitting the hard drive.  One solution to help aide this is to have a faster hard drive when building.  I personally recommend a 10000 RPM hard drive.  My favorite, which I have myself, is the Western Digital VelociRaptor.  You can get it in either 150 GB or 300 GB and its SATA 3.0 GB/s.  When I made this switch on my home computer, I noticed the difference.  If you’re running into these sorts of problems, this solution can be extremely helpful.

Another cause is multiple instances of Visual Studio open at once.  You need to be careful with this, particularly if you run Visual Studio plugins.  The problem is that Visual Studio generally can handle it, but some of the plugins use exponentially more CPU and/or more memory when multiple instances of Visual Studio is open.  I suspect this has to do with the Visual Studio plugin architecture.  On the same token, huge solutions also tend to gain disproportionate levels of overhead.  I once worked with a solution that had two hundred subprojects.  Visual Studio and Intellisense operated like a dog in these scenarios.

Additionally, sometimes the layout of projects and source code may be part of the culprit.  One tip for alleviating this a bit is minimizing header code, and putting template libraries like STL and Boost into precompiled headers whenever possible.  The less time deep layers of header code that are hit, the more stably Visual Studio will run.

Intellisense Stops Working

Another common problem is that intellisense partially or completely stops working.  In other cases, perhaps debugging starts failing.  The most common cause is a corrupt NCB file.  My suggestion is to do a batch build, select all and clean everything.  Then, close Visual Studio, delete the .ncb file and any other temporary files Visual Studio may have been using.  Reopen, rebuild, and get a cup of coffee.  By the time you return, intellisense should have kicked back in, and generally will start working again.  If it doesn’t help, there are some deeper tricks, that I can discuss in a future article.  Also, don’t ever check a .NCB file or other temporary file into source control.  They get huge and change constantly, leaving you with a mess.

Quick Build

This is a trick for if you want to build from scratch and will only work if your files were statically linked together.  You can write a simple script which will gather all the cpps in your project and generate a file called something like BuildAll.cpp.  In it, you would do the following:

#include "File1.cpp"
#include "File2.cpp"
...
#include "File99.cpp"

This trick basically takes a complex more modular build and lumps it together.  The build speed increases greatly, because you are guaranteed that every header file will only be compiled once.  This is a nice “hack” for making a build quicker.  Of course, it is not applicable for systems which tend to use a more dynamically loaded model.

Quick Navigation

One known trick for navigating in a file is to set a bookmark, and then use bookmark navigation to go back to a previous bookmark when you’re done editing or reviewing another area of a source file.  You can toggle the bookmark using Ctrl+K.  You then can navigate to the next bookmark using F2 and the previous bookmark using Shift+F2.  This is a very useful technique.  However, I find that the position of those keys doesn’t flow so easily with my typical workflow.  So, I use a “hacky” and more portable version across different IDEs.  This technique is useful if you merely want to take a peek at a different section of code, but not modify it.  You can perform essentially the same thing as the bookmark change, by intentionally injecting a code change at the line you want to go back to (e.g.: type a space).  Then, navigate to the code you want to take a look at.  When you’re done, hit Ctrl+Z and you’re back where you started.  This is hacky, but for whatever reason, my fingers like it better.

Additionally, most of you probably know about go to definition and go to declaration.  To get back, I do often use the bookmark technique.  I set a bookmark at the line right before I hit go to definition or go to declaration.  Then I hop in.  When I’m done, I hit Shift+F2 and I’m back where I started.

Building Multiple Projects at Once

This is a major one, introduced in Visual Studio 2005.  Visual Studio doesn’t make it necessarily clear that this is what it’s doing, but it will, assuming you have your settings configured correctly.  When you build a solution, you can set dependencies on projects.  You should only set a dependency if project A cannot build successfully until project B is built.  As a side effect (bonus?), this implies that project A links to project B and Visual Studio will treat it as a such.  By following this simple rule and being minimalistic about only setting dependencies when necessary, you give Visual Studio a lot of freedom in building your solution.

For example, imagine there are library projects A, B and C, DLL projects D, E and F, and executable G.  D depends on A and B.  E depends on C.  F depends on A, B, C.  G depends on D, E, F (assuming D, E, F create import libraries.  If not, you may even be able to have G dependant on just A, B, C).  Taking this scenario, let’s say we now start a build:

  • A, B and C start building at the same time.
  • A finishes.
  • B finishes.
  • D now starts, while C is still running.
  • C finishes.
  • E and F both start, D is still running.
  • Once D, E and F all finish, G starts.

Let’s say now that each project takes the following amount of time:

  • A – 10 seconds
  • B – 15 seconds
  • C – 30 seconds
  • D – 60 seconds
  • E – 25 seconds
  • F – 20 seconds
  • G – 20 seconds

If done sequentially, this build would take 180 seconds (3 minutes) (Side note: Or if you set no dependencies, it would run faster, but fail and you would likely need multiple passes).  If done with the dependencies set properly, it only takes 135 seconds.  That’s a 25% savings.  That’s not bad when you only have seven projects.  Scale this up to a solution with 50 projects.  If done right, you could easily save a few hundred percent.

One additional nice thing Visual Studio 2008 introduced is the ability to compile individual files within a project in parallel.  You can use the /MP switch on the command line to tell Visual Studio to compile object files in parallel, and this will also give a nice speedup.  Note that the minimal rebuild (/GM) switch is incompatible with /MP.

Conclusion

Hopefully you have found these tips helpful.  I know a lot of other tricks and tips, and so I will probably post a follow-up with some additional ones that I find useful.

Some Helpful Links:
http://www.highprogrammer.com/alan/windev/visualstudio.html
http://www.catch22.net/tuts/vctips

· · · · · · · · · ·

Theme Design by devolux.nh2.me