Thread: VS2010 vs VS2008

>The intellisense for it is rock solid, even in the face of things like boost, etc.
Of course, the instant you try to write anything remotely non-trivial in C, you'll want to go back to a previous version until they fix the bugs.

2008 bugs/changes that annoy me

• Multi-thread compiles fail quite often. One or more of the threads fail to close certain files thus causing mt.exe to return an error thus causing your compile and link to fail. Sometimes it requires you close MSVS and re-open it. Other times it just requires a rebuild.
• Project settings include/lib paths. If you have multiple projects in a solution and you attempt to change paths on a non-startup project the path is relative to where the startup vcproj is located. It should understand that when you click on a different project that it should use the location of it's vcproj as the starting point. What this amounts to is you cannot rely on the auto-complete for include paths and linker paths in any non-startup project within a solution. 2003 and 2005 do not suffer from this problem and I hope 2010 does not either.
• Intellisense looks to be the same as 2005. Hardly any changes/improvements except on the C# side.
• C# keywords are still picked up and color coded in a C++ project
• Does not flag certain comments and place on the task list during compile as 2003 did
• Does not allow you to alter project settings in memory without setting the file to writeable. Very annoying when working with SCM software. 2003 and 2005 allowed project alterations and then when you would compile it would tell you the project file is read-only at which point you would check the file out. This new behavior forces you to check the file out before making project setting alterations and this is the only time 2008 requires this. For all other file types it will allow you to alter them in memory and then when you compile it will show the read-only dialogs. I think they did this b/c of complaints where one could accidentally click somewhere in the solution explorer and grab something accidentally and place it somewhere else.

2005 bugs/changes that annoy me

• Does not pick up changes in cpp files and/or header files when you attempt to start with debugging. It should pick up the changes and recompile those specific cpp's but often it does not. This usually results in you scratching your head as to why your program acts as if you didn't change anything yet your code shows that you did.
• Intellisense is marginally better than 2003. Function browser finally works.
• C# keywords are picked up in C++ projects and are color coded.
• Does not flag certain comments and place on the task list during compile as 2003 did - only works for currently open documents...essentially worthless since you would have to open every file in your project to get this to work.
• With 3rd party integrated tools it often creates two separate entries on the taskbar and one has no title at all but does have the VS2005 icon.

2003 bugs/changes that annoy me

• Using wchar_t as an intrinsic type. In 2003 even if you failed to check this option and used wchar_t it would compile. This is b/c several CRT files typedef'd wchar_t to unsigned short. However the mangled names is where the problem comes in. If you mix a 2005, 2008, or 2010 DLL that is setup to use wchar_t as an intrinsic type and attempt to have a 2003 app that does not have wchar_t setup as an intrinsic type link with those DLLs your project will not link. It is b/c the 2003 compiler incorrectly allows you to compile but the linker will be looking for unsigned short instead of wchar_t. So when it attempts to link with the 2005, 2008, or 2010 DLLs it will be looking for unsigned short...not wchar_t. Huge bug in 2003. You can't fix it by typedef'ing unsigned short to wchar_t in the 2005, 2008, or 2010 DLLs b/c it won't compile. B/c those compilers will correcty see wchar_t as an intrinsic type your code is essentially trying to typedef one intrinsic type to another intrinsic type which flags a syntax error.
• Buggy with respect to wchar_t in the project file. If you never touch the setting in your compiler it will not have any entry for this setting in the xml. However if you set it to TRUE, apply, and then to FALSE, you will see the setting magically appear in your vcproj file. Not really a game killer but annoying when you go to merge project files and wonder why one is different from the other.
• VS2003 will not report a warning on warning level 4 when in fact there should be one reported. On my dev box and one one of my team's dev box our codeline flagged a warning like this but on every other dev box in the company it does not flag the warning and yet they have the same settings and the same exact block of code. I even diffed our project files with theirs and the only difference was the wchar_t entry and header and library paths (since our project was adding some new stuff). I still have not figured out why VS2003 is not reporting the warning on other compilers when in fact it is most certainly a valid warning. It also makes me wonder how many other warnings it has missed.
• 2003's STL flags warnings on warning level 4 which sucks if you have warnings as errors. I believe this is fixed in later compilers.
• C# projects can get completely hosed after a few project saves. Using C# in 2003 is akin to playing Russian roulette with your project. You may open it one day to find out the .cs layout won't load and/or is completely corrupted.
• Allows fully qualified names on enumerations. Problem here is when migrating to 2005+ this will cause a compile failure since 2005, 2008, and 2010 do not require nor allow fully qualified enumeration names.
• Does not require fully qualified names on member function pointers. 2005, 2008, and 2010 all require fully qualified names for member function pointers.
• Certain 3rd party integrated tool windows pop up at startup but can never be found and clicked after startup

Good memory Bubba! I only wish.

It should understand that when you click on a different project that it should use the location of it's vcproj as the starting point.

Fixed, from what I could see. This too was a problem to me as I worked through most of 2008 with a multiproject solution.

Multi-thread compiles fail quite often. One or more of the threads fail to close certain files thus causing mt.exe to return an error thus causing your compile and link to fail. Sometimes it requires you close MSVS and re-open it. Other times it just requires a rebuild.

I use /MP very seldom because most of my builds are incremental. Besides my dependency trees aren't wide enough to actually take advantage of it. However I seem to read somewhere about this problem and learning that it's got something to do with hyperthreading. So, instead of using # of virtual processors (which is the default figure VS will try to calculate), you may want to fix yourself the number to threads to open, by forcing it to ignore hyperthreading. That is:

1 processor, dual core = 2 cores = 4 virtual processors with hyperthreading.

So, set processMax to 2, thus ignoring hyperthreading. And see if that works better for you. Of course, this does render /MP a little less useful. But it's faster than having to redo a build.

Disclaimer: Again, I totally am not sure about this being the actual problem. I'm working from memory...

EDIT: Oh, and another thought. This may be also a function of the OS. Seven is announced to come with better and fixed hyperthreading. So... don't yell at me... upgrading to Windows 7, may deal with it.

So would it be worth a few GB download for 2010? I have 2008, but I have legal access to both professional editions. I'm more interested on the familiarity side of things... i.e.

Given that the chance they have 2010 is 50%, and 2008 is 50%. Would it be better training on 2008 then having to use 2010, or conversely, training on 2010 and having to use 2008?

Originally Posted by Bubba

2005 bugs/changes that annoy me

• C# keywords are picked up in C++ projects and are color coded.

Are you sure those are C# keywords and not C++/CLI keywords?

Originally Posted by Bubba

Really? I have 2008 SP1 and it still has this problem. If it is fixed or we can remedy it please let me know how so I can pass it on to my team. We are totally annoyed at this issue right now.

I meant fixed on the 2010 version. I didn't go through that extensively. But from all I could gather that problem no longer exists in VS 2010.

Originally Posted by mario F

I will always fail to understand this fixation in altering player environments from version to version in a lot of software. It's a complete productivity fail and often an offense to long time users. If you are going to change the colors or your interface, just for the sake of changing, at least make it optional, for pete's sake.

Yes I believe a program should choose a beautiful interface and never change it.