Visual C++ .Net 2003 Standard - How To Optimize 
Friday, October 28, 2005, 12:00 AM - Programming
Problem 1:

Visual C++ .Net 2003 Standard Edition comes with a non-optimizing compiler!
How annoying!!!

Fix to Problem 1:

See this page for instructions on how to get an optimized compiler, and integrate it with the IDE. Microsoft makes the optimizing compiler available to download for free. Now, why would they let you download a free optimizing compiler, but when you pay $100 and actually buy the product, you get a non-optimizing compiler? In the words of a friend of mine, "That's some shrewd marketing. Or something."

Problem 2:

So, everything is hunky-dory now, right? Not exactly, the optimizing options are still grayed out in the GUI, just as the xona.com article mentions. Well, that's not too annoying, since you can just specify /O2 or whatever in the "Additional Options" section.

However, it actually was still very annoying for me because I use cmake (Cross Platform Make) for small projects and it conveniently changes a /O2 into an 'Optimization="2"' in your project file (which is the correct thing to do, if you have a normal IDE that doesn't gray out optimization options and then filter them out before launching cl.exe). Try as I might, I could not get cmake to just put the "/O2" in the additional options. I could put it in there myself manually, but the next time I reload the project, cmake conveniently rebuilds my project file.

I'm not angry with cmake. It's doing exactly the right thing. It's MS fault for giving me a crippled compiler! If they are giving out a free optimizing compiler, why not actually let me use it from the IDE that I paid for!

Fix to Problem 2:

Well, I wouldn't be writing this nice blog if I didn't have a solution, now would I?

There is a function in VCProjectEngine.dll that filters the command-line. Just replace 0x74 with an 0xEB at offset 0x63D7 in the DLL and you're set! (This only applies to VCProjectEngine.dll version 7.10.3077.0. With version 7.10.3274.0 the offset you want is 0x6AB3.)

Best of luck.

[ 1 comment ] ( 2571 views )   |  permalink  |   ( 2.9 / 145 )
NoStepInto (StepOver) with VS.Net 2003 (7.1) 
Thursday, October 27, 2005, 12:00 AM - Programming
Problem:

NoStepInto does not work with VS.Net 2003 on Windows 2000. Sure it is an undocumented feature, but hey, it's quite handy, and would be nice to have.

Longer description:

When you hit F11 in VS.Net to step into a function, sometimes you don't want it to step into certain things, like basic_string constructor, etc.
Visual Studio 6.0 had a way of disabling stepping into certain functions via the autoexp.dat file, but with VS 7.0 and later, you accomplish it by setting certain values in the registry.

Refer to this page to see more about NoStepInto and how it works.

Refer to this page to see the problem with Win2k and the solution Jan Bares came up with.

Cause:

So, after reading that, you can see that because of bug in MS code, a certain variable goes uninitialized, and therefore the GetRegistryRoot function fails, and therefore NoStepInto functionality doesn't work. Now, was this done intentionally, to "encourage" people to upgrade to Windows XP? I don't know.

Fix:

Well, Jan Bares already came up with the solution, which is a hack/patch to the NatDbgDE.dll file, but unless you have access to a disassembler and can figure out how to download the symbol information, it's probably not going to be that easy for you to figure out where the patch goes.

Just nop out the eight bytes starting at offset 0x15103. (Oh, and don't forget to make a backup of your DLL first.)

Hope it works for you too!

[ add comment ]   |  permalink  |   ( 2.9 / 126 )
boost shared_ptr with vs.net 2003 intellisense 
Thursday, August 25, 2005, 12:00 AM - Programming
Problem:
Intellisense doesn't work with boost::shared_ptr. I am using boost version 1.32.

Longer description:
Here is a code sample:

class foo
{
public:
bool func() { return true; };
};

boost::shared_ptr<foo> pfoo;
pfoo.get();
pfoo->func();


No intellisense pops up after the . or the ->. I love shared_ptr, but having no intellisense makes things really annoying.

Cause:
I think it's because VS.Net does not look at the appropriate header files. It probably could do a better job and maybe it does in VS 2005, but then again, perhaps it would slow it down to try to parse through many more files?
As a side note, I tried Visual Assist and it sort of worked, but sometimes it actually popped up the wrong intellisense, whoops! Also, I did notice that it had to parse through a lot of files.

Fix:
At first glance, you would think that adding boost\shared_ptr.hpp to the project (add exiting item) would solve the program. It ALMOST does, but you need to add that file AND boost/detail/shared_ptr_nmt.hpp. At least, that is what I have to do with boost 1.32 to get it to work.

Hope it works for you too!

[ add comment ]   |  permalink  |   ( 3 / 113 )
NUnit for C# 
Tuesday, June 7, 2005, 12:00 AM - Programming
NUnit rocks! 'Nuff said.

[ add comment ]   |  permalink  |   ( 2.9 / 119 )
.Net, C#, and Visual Studio - Duplicate Declaration of Member Location 
Saturday, March 19, 2005, 12:00 AM - Programming
Problem:
I get this error message: "Duplicate declaration of member 'location'"

Longer description:
When I try to pull up a form in design view, all the controls show up in the top-left corner of the form, and the error message appears in the task list. The form itself is not all that complicated.

Cause:
Beats me, but I read somewhere something about a race condition with compiling versus bringing up the form. Also, I found a hotfix from Microsoft, but it looks like it is only for when the error occurs when you are opening a solution. Also, it says it is for Japanese version only... Well, that doesn't help me...

Fix:
I fixed the problem by deleting all the intermediate files (.dll and other binaries) and restarting visual studio. Good luck.

Additional Notes:
(2005-Apr-28):
At least one other person who received this problem was not able to solve it by simply deleting all the .dll files. They were using source control, and after a clean checkout, things worked fine. This leads me to believe that possibly the .csproj.user and/or .suo files are also partly to blame. That's also what the microsoft workaround would seem to suggest.

[ 1 comment ] ( 538 views )   |  permalink  |   ( 3 / 142 )

Back