using C# when adding new feature

[Tony Johansson]

Hello!

We have MFC application from VC6. Assume we compile the MFC application in
VC8.
Does anything special be done to the MFC application accept remove all the
errors before being able to use .NET
for new feature.

When we want to add new feature to the application using .NET is it then
possible to use C# insted of C++?
I just think that it would be an advantage using C# instead of C++ will
cause less error beacuse it's an easier language. Compare this you create an
application quicker when using Java then C++ beacuse it's an easier language
and the possibility of strange errors in the future is much less with Java.
C# is quite similar to java.

//Tony

 

[Carl Daniel [VC++ MVP]]

Hello!

We have MFC application from VC6. Assume we compile the MFC application in
VC8.
Does anything special be done to the MFC application accept remove all the
errors before being able to use .NET
for new feature.

When we want to add new feature to the application using .NET is it then
possible to use C# insted of C++?
I just think that it would be an advantage using C# instead of C++ will
cause less error beacuse it's an easier language. Compare this you create
an application quicker when using Java then C++ beacuse it's an easier
language and the possibility of strange errors in the future is much less
with Java.
C# is quite similar to java.

Yes. If you get your VC6/MFC code to compile on VC8 with /clr (resulting in
a managed app - or at least a partially managed app), then you can implement
new forms in C# and use them in your MFC application.

Whether it's any easier or less error prone is a more controversial
question. I'd argue that the primary reason languages like C# and Java are
easier to program in has more to do with the framework (.NET or Java) than
language syntax.

It's very easy to create WinForms in C++ and you shouldn't have any more
errors in those forms than their equivalents in C#. Given that you already
have a C++ application (and hence, C++ experience), I'd expect you might
even have fewer errors if you stick to C++ for new work regardless of
whether it's managed or native.

-cd

 

[Lloyd Dupont]

You should know that writting in C# is a much better, less bug prone
exception.

I haven't done real measure but I won't be surprise if the same code in
ManagedC++ is typically 50% bigger (in term of byte size of the source code
files) for writing the same set of functionalities.
That 50% time to write & 50% more opportunity for bugs!

As for pure (unmanaged) C++, some features are simply unavailable or hard to
mimic.

On the other hands in some case using ManagedC++ is a much better solution
than C# if you've got complex interop or lots of function to 'redeclare' in
C#.

 

[Marcus Heege]

You should know that writting in C# is a much better, less bug prone
exception.

I haven't done real measure but I won't be surprise if the same code in
ManagedC++ is typically 50% bigger (in term of byte size of the source
code files) for writing the same set of functionalities.
That 50% time to write & 50% more opportunity for bugs!

As for pure (unmanaged) C++, some features are simply unavailable or hard
to mimic.

On the other hands in some case using ManagedC++ is a much better solution
than C# if you've got complex interop or lots of function to 'redeclare'
in C#.

Many of your observations are true for the old C++ Managed Extensions
syntax, but not fo the new C++/CLI syntax.

In some cases, C++/CLI is still more code to write, like in this one:

<code language="C#">
Sting Text {
get() { ... }
set() { ... }
}
</code

<code language="C++/CLI">
property Sting^ Text {
String^ get() { ... }
void set(String^ value) { ... }
}
</code>

but on many cases it is even less code:

<code language="C++/CLI">
property String^ Text;
</code>

will automatically allocate the backing storage and implement getters and
setters.

The biggest coding benefit comes with implicitly dereferenced access and
interop:

<code language = "C#">
class X : IDisposable {
private Object oLock = gcnew Object;
private Mutex mtx = gcnew Mutex(...);

public void Dispose() {
mtx.Dispose();
}

public void f() {
lock(oLock) {
using (FileStream fs = gcnew FileStream(".....", ....))
using (...) {
...
}
}
}
};
</code>

<code language = "C#">
class X {
Object oLock;
Mutex mtx(...);
public:
void f() {
msclr::lock(%oLock)
FileStream fs(".....", ....));
... other implicitly dereferenced things ...
...
}
};
</code>

C++/CLI has many advantages here:
1) It is not necessary to implement IDisposable yourself, the compiler does
this for you.
2) Notice that C#'s lock is a language construct while msclr:lock is a heper
class that comes with C++/CLI. It is easy to implement your own helpers and
even the standard one has a feature, that you will miss in C#:

msclr::lock(%oLock, 2000);
Acquires the lock with a 2 second timeout.

Marcus Heege