C++/ATL migration to C#

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,

Can anyone please do one favor for me?

I have one project in c++/ATL , that I want to convert into C#.
I have following doubts over this migration.

1. what will be the option for existing header files? I mean can we use
existing one or we have to rewrite in C# from starting but as far as I know
there is no concept of header files in c#.

2. We have COM interfaces in ATL project so if we implement in C# do we have
to write same thing to implement some basic functions like IUnknown
etc..(please not we don't want to import using RCW)

3. If we use VC8 instead of C# how much it will be better performance wise
and migration effort wise, can u please suggest some ur ideas?
4. Can you please suggest some websites or urls where i can ger more info
that may helpful in this migration.?


The requirement is like that we have to migrate from existing C++ to Dotnet
and then compare performance.

Thanks in advance,
Madhur
 
1. what will be the option for existing header files? I mean can we use
existing one or we have to rewrite in C# from starting but as far as I
know
there is no concept of header files in c#.
Click to expand...

There is no concept for header files in C#
2. We have COM interfaces in ATL project so if we implement in C# do we
have
to write same thing to implement some basic functions like IUnknown
etc..(please not we don't want to import using RCW)
Click to expand...

RCW is the only option you have in C#. The CLI has a .vtfixup feature to
control vtables, but C# does not use them. If you can affort to wait ~ 2
more months and to use .NET 2.0, I strongly recommend you to use C++/CLI
which uses this .vtfixup feature and provides many many other advantages for
the migration of C++ code. Some of them are:
* You can compile existing your code into .NET code and extend it with .NET
features
* You can leave your existing code as is and add some .NET code to it
* You can easily call native functions from managed code and vise versa
* You do not need RCWs to call COM Objects
* You can use native types in your .NET code
* You can integrate WinForms UIs in MFC code

If you cannot afford to wait that long or to be fixed to .NET 2.0, you can
use VS.NET 2003 and the so called C++ Managed Extensions. You should also
note that C++ Managed Extensions code can be compiled with the
/clr:oldsyntax flag of VC++ 2005, too.
3. If we use VC8 instead of C# how much it will be better performance wise
and migration effort wise, can u please suggest some ur ideas?
Click to expand...

Performance absolutely depends on your code. Migration effort is much
cheaper with C++/CLI than with C#.

Hope this helps

Marcus Heege
 
madhur said:
2. We have COM interfaces in ATL project so if we implement in C# do
we have to write same thing to implement some basic functions like
IUnknown etc..(please not we don't want to import using RCW)
Click to expand...

If you want other code to use your COM objects (COM interfaces are
*always* part of a COM object) then you have no choice - you have to
implement COM object some way. In this situation I usually tell my
clients to leave the COM objects as COM objects. The .NET code can use
COM interop to access them. The reason is that if you've tested and
tuned them already for COM then you'll have to repeat all of that for
..NET. COM interop works, so use it.

If your objects will *only* be called by .NET objects then you do not
need COM. .NET objects can have interfaces. There's no equivalent of
IUnknown, because reference counting is not used, language casts are
used in place of QueryInterface. .NET interfaces also have inheritance.
In fact, interfaces in .NET make a lot of sense and can make your code
more polymorphic.
3. If we use VC8 instead of C# how much it will be better performance
wise and migration effort wise, can u please suggest some ur ideas?
Click to expand...

That is debateable. Think about the issues. You compile the code to IL
and then the IL just-in-time compiles the IL to x86 before the code is
run. The JIT compiler is common to *all* IL created by *every* language,
so language differences can only affect the IL that is generated. I've
looked at alot of IL produced by Microsoft's compilers and although
there are differences they are not significant in terms of performance.

So you choose the language according to the features it offers. C++
offers templates as well as generics and hence offers template
libraries. If you need those, then C++ is the way to go.
The requirement is like that we have to migrate from existing C++ to
Dotnet and then compare performance.
Click to expand...

Well, I have done this with a Fast Fourier Transform and known test
data. (I used an FFT because it was computationally intensive.) I
compiled to unmanaged C++ with various optimizations (speed, size). Then
I made a few minor changes (mainly in array allocations and trig
function calls) and then recompiled as managed C++ with various
optimizations. For the same test data, with the JIT compile time
discarded, I found that managed C++ was marginally faster than unmanaged
C++. When you think about it, this makes sense because the JIT compiler
can be thought of as being the 'back end' of a conventional compiler. So
the output code should not be slower. Of course, the JIT compilation
does take time.

Richard
 
Back
Top