views:

114

answers:

4

We have a large MFC/C++ Visual Studio 2005 solution which currently consists of two projects:

  • Code (around 1500 .h/.cpp files, linked dynamically to MFC)
  • Resource DLL (we translate the resources using an external tool)

What options do we have (lib, dll, ...)? Where do we start? Is there a technical sample of this or a tutorial (I could not find anything)?

PS: We have no experience with creating dlls and/or libs with C++/Visual Studio yet, so any tips how to get started are appreciated.

A: 

MFC this or not you have to start from extracting business logic from GUI handlers. Once you done this you can put them inside alib.

Mykola Golubyev
A: 

You can remove all resource DLL management by using appTranslator: The tool keeps track of all translations in its project file and creates the resource DLLs for you. One of the benefits is that you don't have to manage all the translated .rc files and associated resource DLL projects in Visual Studio.

Disclaimer: I am the author of appTranslator.

Serge - appTranslator
A: 

This depends very much on the quality of you codebase. If you have nicely encapsulated classes/components that interact through well defined interfaces, it should not be to hard to seperate those into different projects. Also, before you start, think about what you want to achieve. Are there reusable or platform dependent components in the system that you want to isolate? In my department, we have written a set of Visual C++ 2005 Wizards that make sure, that all newly created projects comply to a certain directory structure and organisation (e.g. we can automatically create unit test projects for our libraries). We also use them to make sure that reusable components can be included via SVN externals, which really saves a lot of work.

So, before you look any further, make sure you get you requirements right.

Space_C0wb0y
A: 

Clearly there is no universal answer to you question.

First you need to create some simple program using DLL's or statically linked libs (simply as an exercise). Before you know how to create such application from scratch it is not advisable to attempt fragmenting real-life project. There are couple of MS tutorials here and here for static libraries and DLLs correspondingly.

After that you can approach your application. First try to understand the structure of your project. Ideally you would be able to figure out GUI part, business logic and back end.

The easiest usually is GUI (because business logic is often interwoven with backend, my prediction you are going to have hard time separating those two). Move all the files that drive GUI (dialogs, user event handlers and such) into separate DLL. Once GUI is separated look at the rest. From my experience next thing to do is to separate utilities, that are used everywhere in your application but do not really depend on the application state (or provided with relevant state on every call). While doing so you will learn a lot about the rest of the project, hopefully enough to fragment it even further. Process is incremental and there is no magic wand. Sorry.

BostonLogan