Upgrading a big project to Visual Studio 8

We’re planning to upgrade a Visual C++ 6.0 project with 1500 classes to Visual Studio 8.0

a) Is it worth to upgrade our project from one compiler to the other? Which would be the main advantages to support this decision?

b) Shall we see a clear decrease of speed while editing code and resources, compiling and linking our project with such big number of classes in the Visual Studio comparing to the results in Visual C++ 6.0? Shall we meet any other typical problems due to the upgrade of a big project from one compiler to the other?

c) Should we upgrade our Visual C++ project directly opening it from the Visual Studio 8.0 or should we start a new project in the Visual Studio and then progressively incorporate the old classes into the new project?

d) Should we change our native C++ classes to managed C++ classes while upgrading to Visual Studio, or should we maintain our classes as they’re defined?

Thanks a lot for your help!

Of course it worth upgrading to VS2008. VS6 is no longer supported in Vista or Win 7. So unless you plan to stick forever to WinXP or prior, you'll have to switch to a newer version. But that's just a started. VS 2008 has a much better compiler, with support to new features that will be added to the C++ standard, known as TR1. This includes containers (tutple, array, unordered map, set), regular expressions, random number generators, smart pointers, and others. In addition it contains an extended MFC library, with new features and controls (like support for Office ribbon). And even more features are planned for Visual Studio 2010.

It might take longer to build in VS2008, but the decrease is not that drastically. However, the IDE is very different, and you might need some time to get used to it.

Yes, you should upgrade by directly opening the solution in VS and let it do the upgrade. Of course keep a backup of your sources (I hope you are using version control). Expect breaking changes, as the new compiler (starting with VS 2005) is much more compliant to the C++ standard, than the one from VC++ 6.

As for the last question, I see no reason for such a thing. I guess you are not very familiar with C++/CLI, so I suggest you do some reading.

Cilu has you well covered here.

There can be a few reason not to convert until a point in time that makes it more comfortable. You'll be in a non-productive mode for a day or two while you sort out compiler complaints.

As a simple example of what you'll see, consider this:

Code:

---


for( int i=0; i < 10; ++i )
    {
      ...
    }

for( i = 0; i < 20; ++i )
    {
      ...
    }

---

In current and compliant compilers, i is not in scope by the end of the block belonging to the first loop. The second loop will generate an error in VS2008, but didn't in VC6. There is a switch you can use to allow this to compile, but you really shouldn't turn that on - you should correct the code (either declare int i in the second loop, or declare int i before the first loop).

The good news is that a substantial majority of your code will compile in VS2008, the optimizations are better - but an observation of speed enhancement is pointless without some study of what your application actually does.

Cilu and JVene:

Thanks a lot for your answers. I still would like to say:

a) We’ve been using Visual C++ 6.0 with our project and it runs perfectly well on Vista. Have you tried Visual C++ 6.0 on Win 7?

b) We made an upgrade of our code 12 years ago from DOS - Watcom C Compiler to Visual C++ 6.0. I realized at that moment that the jump had to be done and the decision was obviously right, but the speed of the complete compiling and linking while we made the change increased a lot. Fortunately hardware always helps you as machines work progressively faster. But in our actual situation, I’m afraid that migrating from Visual C++ 6.0 to Visual Studio 8.0 could imply a hard loss of speed as the VS8 seems to be a too heavy tool to be able to run fast with our project. So I should have a strong reason to migrate from one compiler to the other to assume this risk. Which would eventually be that reason? Any comments?

c) Is there any kind of limit on Visual C++ number of classes in the same project or any other kind of limit that should worry us? Does this limit exist in Visual Studio 8?

d) Is there any other way to reduce time consuming working with a big C++ project?

Thanks!

Quote:

---

We’ve been using Visual C++ 6.0 with our project and it runs perfectly well on Vista. Have you tried Visual C++ 6.0 on Win 7?

---

Yes, but there is no support from Microsoft on this version of VS anymore. So you should not expect anything to work on future versions.

Quote:

---

c) Is there any kind of limit on Visual C++ number of classes in the same project or any other kind of limit that should worry us? Does this limit exist in Visual Studio 8?

---

No, definitely not. I'm working on projects with 1 to 5 million lines of code, many thousands of files and classes and they work well.

Quote:

---

Is there any other way to reduce time consuming working with a big C++ project?

---

Define 'time consuming working with a big C++ project'.

Quote:

---

Originally Posted by lluismc

but the speed of the complete compiling and linking while we made the change increased a lot.

---

Compilers that only knows a subset of C++ (such as the Watcom compiler) will, of course, compile the code faster. The old joke is "my compiler runs faster -- the reason is that it doesn't check for all errors...".

The C++ language has grown since DOS days, and that growth includes ANSI standardization. Compilers have to be more thorough in checking syntax, plus all the additional features that C++ has that have been built into the language. In the days of DOS, C++ compilers were merely glorified 'C' compilers, because that was all that C++ was in the late 80's and early 90's. After 1998 (ANSI standardization), those times have changed.

Quote:

---

Is there any kind of limit on Visual C++ number of classes in the same project or any other kind of limit that should worry us? Does this limit exist in Visual Studio 8?

---

I'm not sure what you mean by "classes". As far as I know, you can define as many classes as you want.

I know one thing, VC 6.0 is a limited compiler. Not only is not not supported by Microsoft, third-party source code vendors dropped support for it. The reason is that many C++ source-code based libraries use templates heavily, and VC 6.0 just cannot handle the code correctly.

Quote:

---

Is there any other way to reduce time consuming working with a big C++ project?

---

Check your dependencies and what files include what headers.

Regards,

Paul McKenzie

Thanks to everybody

I'm now giving an answering to Cilu:

'Define time consuming working with a big C++ project':

Our projects spends an increasing number of minutes while being rebuilt, which I find quite inconvenient. Obviously we don't have to rebuild frequently, but when this happens, you have to wait until the complier finishes to keep on working. I wouldn't like to see that this time increases much more after having upgraded our software to Visual Studio 8.

Yours,

If you upgrade to VS 2008 it will take advantage of multi core processor, and build projects in parallel, one for each core that you have. VC++ 6 is not able to do that.

My 4 million lines of code solution with 60 projects (native, managed, and mixed-mode) takes 20-25 minutes for a complete rebuild. How much does it take for your solution?

Rebuilding our solution (one single project with 1500 classes) takes about 15 minutes. Is there any compiler or linker option or configuration that makes reduce this time? The compiler should have an option to avoid extra checking of the code. If you have previously analysed your code with the complete level of testing, it seems very interesting to relax the code revision to achieve a lower time to build the executable. Does this option exist in Visual C++ 6.0? Does it in Visual Studio 2008?

Thanks!

Quote:

---

Originally Posted by lluismc

The compiler should have an option to avoid extra checking of the code.

---

Then it wouldn't be a compiler. Either the code is going to be valid ANSI C++ code, or it isn't.

Quote:

---

If you have previously analysed your code with the complete level of testing, it seems very interesting to relax the code revision to achieve a lower time to build the executable.

---

There are many invalid C++ code constructs that you are allowed to get away with in Visual C++ 6.0. You won't be able to get away using such constructs in later versions of the compiler, due to more adherance to ANSI/ISO C++.

Similarly, there are legal constructs in ANSI/ISO C++ that are not accepted by Visual C++ 6.0, but are accepted in later versions of the VC++ compiler.

Quote:

---

Does this option exist in Visual C++ 6.0?

---

Visual C++ 6.0 knows nothing about standard C++, since it was created before C++ became standardized. Therefore there is no code to "relax"

Quote:

---

Does it in Visual Studio 2008?

---

No.

No company that I know of, including Microsoft, will produce a C++ compiler that will revert to an "older" mode that allows illegal and improper C++ syntax.

Regards,

Paul McKenzie

On the subject of compilation time:

One of the tenets of project management / layout deals with the subject. It is in several texts, pops up in discussions of design patterns. When an implementation is separated from an interface suitably, it means that the object file created during compilation will tend to require recompilation less often, shortening compile times - sometimes dramatically. You can note this rather obviously if you use any libraries that supply either DLL's or static libraries for incorporation into your project. Pushing the code you'll have to modify less often into files that won't need recompilation is the result of this project organization.

It may be too late to do that in a large existing project. The time required to redesign interfaces in order to separate implementation could be longer than the accumulated compilation time you'd save, so I'm not offering a solution to your current problem as much as I am an plan for how to avoid the problem in the future.



I recall some nonsense in an article from 15 or 20 years ago that actually extolled the feature of increased compilation times. The author had upgrade to a faster processor (either from 286 to 386, or to the 486), and complained that compile times were so fast he didn't have time to sit and think.

We have come a long way.

Paul:

Thank you very much for your ideas.

In another forum a programmer has given the next answer to my question:

“there is an option in vs 2008 for Fast build vs fast code.”

This is the kind of option I’m looking for in Visual Studio 2008. I assume that the compiler must always check that the code agrees with the syntax rules. But the compiler is doing many more tasks than this checking. These tasks are not always useful to the programmer. I wonder whether the Visual Studio 2008 engineers have taken this need into account. Is it possible to configurate Visual Studio 2008 process of compiling/linking in order to optimize different aspects involved while generating the executable?

JVene:

Thanks a lot for your interesting considerations.

Quote:

---

Originally Posted by lluismc

I wonder whether the Visual Studio 2008 engineers have taken this need into account.

---

How many times do you need to do a "release" build (i.e. an optimized build)? Optimization is one reason why the compile time is increased. That is supposed to be a good thing (aggressive optimization is done on a release build).

Your customers shouldn't care one bit how long it takes to compile your application, so long as your final product is fast, or as fast as it should be.

During development, fast compilation, but unoptimized builds are usually always produced. Release builds are done either when you are actually doing a public release of the application, or infrequently (maybe once a week) to make sure that there is nothing wrong with the current code.

Regards,

Paul McKenzie

lluismc, also note that you can download a 90-day trial of VS 2008 and check out all this stuff for yourself.

Hiho peeps,

while also upgrading a huge project to VS 8 I wonder about differences between old MFC and new MFC.

Is the anywhere a document describing in details what is new in MFC9 and what to care about when converting a project??

simply to silly to find it out and with best regards

:wave:

Search for MFC Feature Pack.
http://msdn.microsoft.com/en-us/library/bb982354.aspx
http://www.microsoft.com/downloads/d...displaylang=en
http://www.codeguru.com/cpp/cpp/cpp_...cle.php/c14929

Google on "what's new in Visual C++ 2008." That takes you to an MSDN page. You might also want to Google on "Breaking changes in Visual C++."

Thanks guys! :thumb:
(http://www.microsoft.com/downloads/d...displaylang=en seems to be a broken link though)