From native to managed

[=?iso-8859-1?q?Erik_Wikstr=F6m?=]

I'm working on a project where all the current code is written in
standard compliant C++ with no dependencies on any external libraries
except the standard library. The application is used to perform
simulations of thermal radiation and is highly performance sensitive
and as such we have no plans to rewrite it in managed C++. However we
want to add a graphical user interface to it and we are looking at
using the .Net framework to do so, probably using managed DirectX to
visualize the 3D models used in the simulations.

We have no prior experience with managed C++ so we are wondering what
would be the best approach to this, should we start a new project and
integrate our existing code together with managed code for the GUI and
compile some parts native and other managed. Or would it perhaps be
better to create a DLL/LIB of the existing code and make calls to it
from the GUI?

We don't expect a lot of interaction between the current code and the
GUI, mostly passing some values (ints, doubles), a list of pointers to
structs describing the model (std::vector<Cell*>) and perhaps perform
some callbacks for status/progress notifications.

All advice welcome, and if you happen to know of any good articles on
the subject please tell.

--
Erik Wikström

[Bruno van Dooren [MVP VC++]]

I'm working on a project where all the current code is written in
standard compliant C++ with no dependencies on any external libraries
except the standard library. The application is used to perform
simulations of thermal radiation and is highly performance sensitive
and as such we have no plans to rewrite it in managed C++. However we
want to add a graphical user interface to it and we are looking at
using the .Net framework to do so, probably using managed DirectX to
visualize the 3D models used in the simulations.

We have no prior experience with managed C++ so we are wondering what
would be the best approach to this, should we start a new project and
integrate our existing code together with managed code for the GUI and
compile some parts native and other managed. Or would it perhaps be
better to create a DLL/LIB of the existing code and make calls to it
from the GUI?

We don't expect a lot of interaction between the current code and the
GUI, mostly passing some values (ints, doubles), a list of pointers to
structs describing the model (std::vector<Cell*>) and perhaps perform
some callbacks for status/progress notifications.
================================================== ======

Hi,

There are several options. however, for the sake of flexibility and
maintainability, I would choose one of the following 2 approaches:
- leave the code as it is (unmanaged code) and add a set of native classes
that will be compiled with /clr. create a set of WinForms classes that
implement whatever you want for the GUI and access that through that set of
classes.
By doing this you have an abstraction layer between your GUI and your app
itself. Should you later decide to use OpenGL or something else, you will
only have to change the UI classes implementation.
- refactor the code to be a DLL native project. Then create a winforms
application that calls into your DLL. this allows you to distribute and
update the algorithms as a separate unit, should you ever want to.

The key thing here is that you mentioned that you have standards compliant
C++ code, using the STL.
Currently there is no way to make C# or VB work with STL classes. That means
that you have to use C++/CLI for your GUI part.

That is no drama, but I tell you this so that you don't turn your project
into a DLL with the intention to invoke it in a C# application.
It wouldn't work without abandoning the STL.

--

Kind regards,
Bruno van Dooren
br**********************@hotmail.com
Remove only "_nos_pam"

[Ben Voigt]

The key thing here is that you mentioned that you have standards compliant

C++ code, using the STL.
Currently there is no way to make C# or VB work with STL classes. That
means that you have to use C++/CLI for your GUI part.

That is no drama, but I tell you this so that you don't turn your project
into a DLL with the intention to invoke it in a C# application.
It wouldn't work without abandoning the STL.

Well, you wouldn't have to abandon the STL or rewrite existing code, but you
would need to provide conversion functions to create .NET
System.Collections.(Generic.)List objects from each vector in order for C#
to be able to access them. That isn't too hard, and creating a template
implementation of IList<that proxies all access to a stl::vector for any
type wouldn't be difficult.

>
--

Kind regards,
Bruno van Dooren
br**********************@hotmail.com
Remove only "_nos_pam"