Home/ Questions/Q 920229
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T18:40:42+00:00

Currently, we are working on a C++ legacy code base, which consists of several

  • 0

Currently, we are working on a C++ legacy code base, which consists of several software components.

One of the components, are written in a way that is extremely difficult to maintain. (For example, memory allocation is done in X place, but memory de-allocation is done in Y place. This make memory management a painful job). Till now, we able to solve (or workaround) all the memory leakage issues.

However, after several rounds of bug fixing, our feeling is that, due to the high maintenance cost of this software component, we are unable to go too far from current milestone.

I know it might be bad to rewrite the source code : http://www.joelonsoftware.com/articles/fog0000000069.html

However, instead of re-factor the current code, we forsee it will be better to re-write from scratch due to

  • Till now, no one in the team can fully understand that software component code.
  • The legacy software component is a small piece of software. 20k lines, I guess
  • Our teams are pretty clear on the requirement and what we are trying to achieve

Hence, we are planning to go for a managed code, at least make memory management a painless job. We plan to choose C#, as

  • All our C++ code are compiled using Microsoft VC++
  • We are using MFC, in other software components. (in DLL form) Every DLL, do have their very own resource.

I am from C++ and Java background, and know nothing much on C#.

  1. How well C# to interface with MFC DLL, with some of the DLL functions will invoke MFC GUI?
  2. Anything I need to pay attention on it?
  3. Will the interfacing with legacy C++ DLLs be easier, if we are using Managed C++?

Thanks.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I am in a similar situation and I also did some experiments mixing C++ and C#. The problems in my application however were that:

    • the application is not clearly split up in different modules, making it hard to move specific modules from C++ to C#
    • the application is quite cpu-intensive and experiments revealed a big overhead in calls from C++ to C# or C# to C++

    Additionally, you cannot call C# directly from native/unmanaged C++, which meant that I had to introduce an additional intermediate C++/CLI (or is this called C++.Net?) layer.

    Therefore, I chose not to move to C#, but stay with C++.

    So, if you want to move from C++ to C#, make sure:

    • that you have clearly separated modules
    • that the transition (calls) from C++ to C# or vice versa are in a place that is not used that often (so not during cpu-intensive tasks)

    Additionally, remember that if you are not the sole developer of the project, that all (or most) of your developers should also learn C#. You don’t want to delegate all C# code to your latest junior developer, because if he leaves, you will be (or could be) in trouble.

    • 0