your experiences on porting code to C++/CLI, please

[Ian]

I would like to hear from others who have considered and/or ported code from
traditional C++ to C++/CLI.

The class library I am considering porting to C++/CLI was written in
traditional C++ with STL and a touch of MFC. It represents the back end to
my applications and, among a number of other things, it performs all file
I/O and data management operations (i.e. no GUI). Why would I consider
porting it to C++/CLI when it works just fine now? I consider myself to be
somewhat less than the average developer because I have no formal training
in software development but rather picked it up out of necessity. When MS
created dot.net it probably had guys like me in mind. Dot.net promises to
make it much easier and faster for me to develop applications. While
develpers more talented than myself can easily get by with pre-dot.net
technology, I have not been so fortunate. The information I've read so far
indicates it will be much easier for me to work with SQL, XML, data bases
and, you name it, in dot.net.

Having said the above, my current impression (and admittedly I have only
limited experience working with C++/CLI) is a port is clearly not a trival
task particularly because the libarary makes extensive use of STL with a
touch of MFC (i.e. CString and CFile. I am beginning to think it would be
better to rewrite the library from scratch over a period of 6-10 months then
to try porting existing code. I'll spend another week or two running more
tests and doing some more research. But I would appreciate hearing from
other C++ user about their experiences in porting their code to C++/CLI (or
even C# for that matter).

Thank you in advance for your input and comments,


Ian

 

[Tamas Demjen]

The class library I am considering porting to C++/CLI was written in
traditional C++ with STL and a touch of MFC. It represents the back end to
my applications and, among a number of other things, it performs all file
I/O and data management operations (i.e. no GUI). Why would I consider
porting it to C++/CLI when it works just fine now?

I don't know about you, but I don't even consider rewriting my back-end
in C++/CLI. I don't use MFC, and I don't use any other framework for
non-visual code (I have a Borland background, but learned years ago to
separate my non-visual code from all GUI-frameworks, so I have no IDE /
compiler dependencies for my back-end). I use STL and boost::shared_ptr,
which compile fine in C++/CLI as unmanaged code. It would be a
tremendous amount of work to rewrite everything, which is unnecessary,
unless the code really has to run in a .NET virtual machine. On the
contrary, I still develop new non-GUI code in ISO C++, without using any
GUI-related framework features.

What I do, instead of rewriting code, I just wrap it into ref classes.
It's easier than putting a COM wrapper around C++ code, it's just
boring, it involves duplicating your public API. But once it's done,
it's available for any .NET language.

Fortunately I don't rely on MFC classes, but I don't see why you
couldn't junk link MFC to a mixed-mode project. I've used native DLLs
from mixed-mode projects, my own and 3rd party as well.

Tom

 

[Ian]

Ian wrote:


Fortunately I don't rely on MFC classes, but I don't see why you couldn't
junk link MFC to a mixed-mode project. I've used native DLLs from
mixed-mode projects, my own and 3rd party as well.

Tom

Hello Tom,

I discovered this weekend that I can take existing code + STL and compile it
in CLR mode (I still haven't figured out how to do this with MFC but I'm
working on it). But this appears to be what you have been doing all along.
The chapters "Unsafe/Unmanaged C++" in Fraser book (Pro Visual C++/CLI),
various NG postings and several codeproject articles (e.g.
http://www.codeproject.com/useritems/usingcppdll.asp) lead me to believe I
would have to use P/Invoke to access my class libraries.

My backend code is non-GUI so based on the your information I should be able
to mix my class libraries with managed C++ and avoid porting my class
libraries to dot.net.

You mentioned you wrap your non-GUI ISO-C++ code in ref classes. Why would
you do this if you can simply call these new functions and/or objects from
unmanaged code? That is, why would you add the overhead of wrapping
unmanaged code in ref classes?


Thanks for your input,

Ian

 

[Tamas Demjen]

The chapters "Unsafe/Unmanaged C++" in Fraser book (Pro Visual C++/CLI),
various NG postings and several codeproject articles (e.g.
http://www.codeproject.com/useritems/usingcppdll.asp) lead me to believe I
would have to use P/Invoke to access my class libraries.

It Just Works. I just call the functions. I don't use p/invoke, the
point of C++/CLI is that you can mix native and managed calls in the
same code. You just have to marshal your data when they're non-trivial
types. An integer, for example, can be passed as it is.

You mentioned you wrap your non-GUI ISO-C++ code in ref classes. Why would
you do this if you can simply call these new functions and/or objects from
unmanaged code?

You're right, it's often not necessary, as a managed method can directly
instantiate and call unmanaged objects. It's always up to you if you
feel wrapping necessary.

That is, why would you add the overhead of wrapping
unmanaged code in ref classes?

If you're a library vendor, for example. If I decide to wrap something,
it's also a specialization at the same time. I would hardly ever want to
wrap an entire native class library directly into .NET objects the way
they are. I would take my general-purpose native library, implement the
functionality I needed for a particular application, and wrap only that
portion, for example, to be called from a C# GUI.

..NET's biggest advantage (in addition to the RAD GUI feature) is its
component model. Native DLLs are very painful to use, and can't easily
be used in a portable plugin architecture. If you use STL classes in
exported functions, you have to compile the DLL and the EXE with the
same vendor's same compiler using the same settings. You're not allowed
to throw exceptions across DLL boundaries. You can't dynamically import
DLLs (there's no way to map a constructor with GetProcAddress). .NET
solves all these problems, and a lot more. It also settles the language
flames -- if someone wants to use VB to write a plugin to my
application, that's possible too. So these are the main reasons of
wrapping, mainly for interfacing, componentizing. I don't wrap my own
low-level libraries, I just call them with IJW.

Note that I don't have production code in .NET yet. I don't want to make
the impression that I'm an experienced .NET programmer, because I'm not.
I just spent a little time researching it. Naturally, the very first
thing I did was implement a dynamically loaded plugin, because that was
my first interest, and learning to effectively mix native code with
managed GUI.

Tom

 

[Ian]

It Just Works. I just call the functions. I don't use p/invoke, the point
of C++/CLI is that you can mix native and managed calls in the same code.
You just have to marshal your data when they're non-trivial types. An
integer, for example, can be passed as it is.


...

Note that I don't have production code in .NET yet. I don't want to make
the impression that I'm an experienced .NET programmer, because I'm not. I
just spent a little time researching it. Naturally, the very first thing I
did was implement a dynamically loaded plugin, because that was my first
interest, and learning to effectively mix native code with managed GUI.

Tom

I've just started testing dot.net code and your information has been
helpful. Thanks again and all the best.

Ian

Thanks again