C++ vs. C# (new to windows programming)...

[Volker Hetzer]

Hi!
After messing around for some time with Tcl/Tk and VBScript,
we've finally reached the point where we need to put some speed
into our applications.

So, our typical application looks like this.
We've got this huge CAD tool, called Mentor Expedition, which
understands VBScript and JScript and offer an ActiveX-Interface
for Automation.

What we typically do is we have an application Gui which is
separate from the tool (Tcl/Tk), then connects to the tool and
accesses Automation objects.
This incurs a big overhead and limits performance to about 100
calls per second. This is way to slow.

We then did a few VBscript components and let that Mentor-Tool
run those via VBscript. That got us quite a speedup for as long
as we limited ourselves to getting data and iterating over
collections.

Now we are at a point where the VBScript needs to do some "real"
calculations too, like geometric transformations.

Therefore we are thinking of introducing a new animal into our
language zoo for the real high speed stuff.

The idea is to put the performance critical parts into a COM
component or, in fact into anything that can be loaded via the VBscript
createobject call, gets the Handle of some big Automation object,
runs in-process, maybe does a bulk insert into an oracle database
on the side (using oracle ole db) and can return complex objects
back to VBScript, like dictionaries or other self defined collections.
We are not really interested in Gui's, more in building blocks.

I've got a bit of experience in C++ from about ten years ago
on Linux.

Right now I'm tending a bit towards C++ for the speed and the
deterministic destructor calls, but I am absolutely glueless about
Windows programming in general, except for VBScript command
line tools.

What would you suggest?

Lots of Greetings and Thanks!
Volker

[Israel]

I've been using C++ for about 10 years (professionally) and only
dabbled with C# when it first came out in 2000 but in the last year
I've moved completely over to .NET and C# at a new company. The only
exception is for the direct show aspect of our product since C++ is the
only viable interface for writing filters at this point.
With that being said there should be no reason why mathematical
operations in C++ should be any faster than in C# unless you are
somehow exploiting some mmx routines that C# *may* not support. The
issues you need to concern yourself with are the communications; making
a lot of consecutive remoting calls (cross process) will incur more
timing overhead than a straight C++ call but I don't know where it
stands in terms of a COM call (which is what you were using before).
In addition the interop calls that will be required to/from a non-.NET
application will incur some extra overhead.
Personally I would suggest trying C# vs. C++, especially if you're
not proficient with windows programming in C++. I've never been a
big fan of MFC and trying to traverse the on-line help to decipher the
organizational logic of winapi methods has driving me insane over the
years and forced me to resort to trial by error because it was easier
to figure out what I should *actually* pass to a method to make it do
what I want. It's such a hodge podge collection of methods and
overrides that has evolved over time that it would be a nightmare for a
new comer. With the .NET complete reorganization I often find that the
namespaces, objects and methods are completely intuitive and I don't
even have to look at the help I just use the intelligence to find the
methods by looking for names that I would have called them and then
look for the override that passes that parameters that make sense to
me.
I've noticed a very large boost in productivity since switching over
to mainly C#. When I re-visit the direct show filter graphs I'm
reminded of how much time I've spent, over the years, just dealing
with silly compilation and linking errors that I just don't see when
using C#. Our application has a constant communication a database and
with various hardware components over a tcp connection to monitor and
control a microscope. I haven't done a lot of testing on rigorous
computations, which I will need to perform in the future to for tasks
like automatically focusing, but I'm completely confident that I can
do everything I need to do in C#.

In summary, you may hit different performance issues with C# vs. C++
but there should be a solution in C# that achieves the desired
performance. In terms of a learning curve using C# will be at least an
order of power easier than C++ to produce and maintain viable code.
You should do diligence and prototype the anticipated interactions with
your application using a C# application and if you run into performance
issues there are plenty of google groups members that will probably
have good suggestions to solve them.

Side note:
When I first started using C# the non-deterministic destructors really
bothered me because I had grown accustomed to implementing solutions
using them like synchronization and opening files etc. It hasn't
taken me too long to get used to designing things a little differently
and utilizing try..catch..finally blocks a lot more or using
IDisposable.

[DHarry]

I think you forgot to say something about reverse engeneering in C#! That's
one of the main points, why I can't decide between C# and C++.

Obfuscation helps you to "protect", but "real" obfuscation is very expencive
and a "normal" programmer can't buy such products. :-(

[Jon Skeet [C# MVP]]

DHarry <DH****@discussions.microsoft.com> wrote:

I think you forgot to say something about reverse engeneering in C#! That's
one of the main points, why I can't decide between C# and C++.

Obfuscation helps you to "protect", but "real" obfuscation is very expencive
and a "normal" programmer can't buy such products. :-(

Does a normal programmer really need such a product though? See
http://www.pobox.com/~skeet/csharp/obfuscation.html

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[DHarry]

Ok.. No Obfuscation any more... :-)

.... but what's with the performance?

I wrote a simple hello world application in MFC (C++) and C# 2.0 and created
two exe files.

If I click on the mfc app, I see a windows in < 1 second.
The C# app windows is shown after 4 seconds.

I think thats anoher point.

[Jon Skeet [C# MVP]]

DHarry <DH****@discussions.microsoft.com> wrote:

Ok.. No Obfuscation any more... :-)

... but what's with the performance?

I wrote a simple hello world application in MFC (C++) and C# 2.0 and created
two exe files.

If I click on the mfc app, I see a windows in < 1 second.
The C# app windows is shown after 4 seconds.

I think thats anoher point.

What exactly did your app look like? Here's a small C# "Hello world"
app:

using System;
using System.Windows.Forms;
using System.Drawing;

class Test
{
static void Main()
{
Form f = new Form();
Label l = new Label();
l.Text = "Hello, World!";
f.Size = new Size (100, 50);
l.Size = new Size (100, 50);
f.Controls.Add(l);
Application.Run(f);
}
}

That comes up pretty much instantly on my box. The very first time you
run a .NET app you may find it takes a little while to load while it
first loads the .NET assemblies off disk, but in that respect MFC is
effectively cheating, and the post-startup performance isn't nearly as
noticeably different.

Now, .NET apps certainly can be slower in UI terms than MFC apps due to
graphic card acceleration differences (I don't know enough on it to
comment properly), but it's not usually an issue IMO. Other performance
is much closer to being on a par with native code though.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[DHarry]

Is use the Wizard in VS 2005. I always take the wizard if I develop
applications.

[Jon Skeet [C# MVP]]

DHarry <DH****@discussions.microsoft.com> wrote:

Is use the Wizard in VS 2005. I always take the wizard if I develop
applications.

Whereas I prefer to have applications which are readable, broken up
into logical blocks instead of one giant initialization method.

Now, did you try my example?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[DHarry]

Yes, I tried it. Less than 1 second

[Israel]

The first time an assembly is loaded (or code is actually executed) it
gets compiled to machine code so there is a first time startup delay.
You do have options to pre-compile everything to avoid this. For an
application that often starts and stops this is probably advisable but
for an application that is meant to run for a long period of time this
isn't as much of a issue.

[Volker Hetzer]

Israel schrieb:

With that being said there should be no reason why mathematical
operations in C++ should be any faster than in C# unless you are
somehow exploiting some mmx routines that C# *may* not support. Ok, what I meant was self contained code that just needs the processor
and no network connections and such. Loops, recursion, searches,
trigonometry too. I agree that things like trigonometry are probably
provided by a fast library, regardless of the language.
The
issues you need to concern yourself with are the communications; making
a lot of consecutive remoting calls (cross process) will incur more
timing overhead Yes, from my timings it's about factor 20 in speed. (VBScript remote
versus VBScript in-process)
One requirement therefore is that our extensions have to run in-process.
For the tool we are extending that means something VBScript can
access using createobject. Which seems to be COM only, either as dll
or as .net assembly(?) with a com wrapper.

Personally I would suggest trying C# vs. C++, especially if you're
not proficient with windows programming in C++. That's what we will do.
I've noticed a very large boost in productivity since switching over
to mainly C#. Where productivity is more important than speed (i.e. for prototypes
and first versions) we use Tcl/Tk here.

In summary, you may hit different performance issues with C# vs. C++
but there should be a solution in C# that achieves the desired
performance. In terms of a learning curve using C# will be at least an
order of power easier than C++ to produce and maintain viable code.
You should do diligence and prototype the anticipated interactions with
your application using a C# application and if you run into performance
issues there are plenty of google groups members that will probably
have good suggestions to solve them. Right now we are also doing a two stage approach. Prototypes are usually a
combination of Tcl/Tk and VBScript and when those have been used for a while
(we do inhouse programming) and requirements are moderately stable we look
at performance bottlenecks and want to do a proper design for version II,
for which we are selecting the tools now. It will also be a layered architecture,
using several programming languages. I can well imagine a combination of
Tcl or VBScript and a small part written in C# or C++, depending on what
profiling suggests.

Btw, here it's not so much about "fast enough" yet.
"Fast enough" in our context would mean less than about 2s. :-)
Right now we have runtimes of 20min and more. With typically six layout
engineers using those programs several times per day, every saved minute
translates directly into productivity at a place where we currently have
a bottleneck.
Side note:
When I first started using C# the non-deterministic destructors really
bothered me because I had grown accustomed to implementing solutions
using them like synchronization and opening files etc. It hasn't
taken me too long to get used to designing things a little differently
and utilizing try..catch..finally blocks a lot more or using
IDisposable.

After reading up about this I think I can agree with that. The C# way
has advantages (I can control the order of destruction) and disad-
vantages (the caller must be more careful) but I think both lead to
less problems than manual resource management.

Lots of Greetings!
Volker