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

  • Thread starter Thread starter Volker Hetzer
  • Start date Start date
V

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.

So, 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 and can return complex objects back to VBScript, like
dictionaries or other self defined collections.
We are not really interested in Gui's.

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
 
Hi,

first of all, if you browse the archives for this newsgroup (on google
groups for example) you will find that this question has been debated quite
extensively (february i think).

I say this not to chase you away, but there were so many posts (the most for
one topic this year) that you will find a lot of information and points of
view.
search for:
Is C++/CLI gaining any traction???
and
C++/CLI the fastest compiler?
read inline for the rest of my comments

Volker Hetzer said:
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.

So, 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 and can return complex objects back to VBScript, like
dictionaries or other self defined collections.
We are not really interested in Gui's.
Click to expand...

Personally (this is just my opinion) I would stay away from COM.
Instead, build a .NET class library. either in C++/CLI or in C#
that way you are developing on technology that is the 'wave of the future'
(tm) and most importantly, you can use the .NET framework classes, which are
awesome.

even if you want to use COM for legacy reasons for your client application,
you can simply register your .NET class library as a COM library and It Just
Works.
I've got a bit of experience in C++ from about ten years ago
on Linux.
Click to expand...

if you go with .NET you have to learn quite a lot anyway. whether you go
with C++ or C#.
check out www.codeproject.com for tutorials and examples.
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.
Click to expand...

The C++ vs C# speed debate has been argued back and forth, an month or so
ago. (see above)
If you go with C++/CLI you can have both the .NET infrastructure and the raw
speed of C++ if you need it.
It also allows you to reuse existing C++ code, should you have any.

there are probably lots of other things to consider, but with a question
like this I think you are going to get a lot of answers :-)

--

Kind regards,
Bruno.
(e-mail address removed)
Remove only "_nos_pam"
 
Bruno said:
Hi,

first of all, if you browse the archives for this newsgroup (on google
groups for example) you will find that this question has been debated quite
extensively (february i think).

I say this not to chase you away, but there were so many posts (the most for
one topic this year) that you will find a lot of information and points of
view.
search for:
Is C++/CLI gaining any traction???
and
C++/CLI the fastest compiler?
Click to expand...
For this post I relied on
http://msdn.microsoft.com/library/en-us/dncomser/html/entsvcperf.asp?frame=true&_r=1
which was IMHO quite clear on which performance differences to expect for which
application type, but I will definitely check out those threads too.
Personally (this is just my opinion) I would stay away from COM.
Instead, build a .NET class library. either in C++/CLI or in C#
that way you are developing on technology that is the 'wave of the future'
(tm) and most importantly, you can use the .NET framework classes, which are
awesome.

even if you want to use COM for legacy reasons for your client application,
you can simply register your .NET class library as a COM library and It Just
Works.
Click to expand...
This was new to me. We will definitely test this.
If you go with C++/CLI you can have both the .NET infrastructure and the raw
speed of C++ if you need it.
It also allows you to reuse existing C++ code, should you have any.
Click to expand...
Thanks a lot!
Volker
 
Andre said:
You could use both.

C++ with a C++/CLI library wrapper for the back end code and C# or any
other language for the GUI part.
IMHO it's more straightforward and somewhat easier in C# and other
managed (only) languages to code a GUI application.
Click to expand...
[lots of good arguments]
Hope my post has helped somewhat.
Click to expand...
It did indeed!

Thanks a lot!
Volker
 
Volker said:
Hi!
Hi,

What would you suggest?
Click to expand...

You could use both.

C++ with a C++/CLI library wrapper for the back end code and C# or any
other language for the GUI part.
IMHO it's more straightforward and somewhat easier in C# and other
managed (only) languages to code a GUI application.

The compiled C++/CLI library can be easily used from any .NET language
and additionally you have separated your GUI from the other code.
Which is a good idea anyway, since a new GUI framework will be
introduced for Vista / Windows XP - Windows Presentation Framework.
Though both frameworks will be supported side by side. And you will be
able to mix them.

I miss some features of C++ in C#, like RAII, but IHMO that's not that
relevant for the GUI part. On the other side C# compiles much faster and
offers more IDE features (better Intellisense, code snippets,
refactoring) than C++/CLI.

C++/CLI will compile to faster IL code, no doubt, but I doubt that you
will see a relevant speed difference for your managed GUI.

For a more (significant) responsive GUI (running on slow PCs) you would
have to choose a native compiler / IDE, which Microsoft offers only for
C++. But using MFC to start a new IDE isn't a good idea - IMHO. You
should IMHO choose another vendor if you want to go that way.

I would suggest you to play around somewhat with C++/CLI and C# and code
some simple GUI applications with both languages. Additionally you
should create a simple .NET library in C++/CLI and see how easy it is to
consume the managed objects / classes from any .NET language you like.
Then you can make a decision of your code.

If you need speed and supporting native code (assembly language, mixing
managed and native code) then C++/CLI is the way to go. But you can
compile this code to a library (dll) which has some C++/CLI objects
wrapping the native code. Which you would have to do anyways in a
C++/CLI only application, because you need to marshal data from and to
native code when mixing native and managed code.
Lots of Greetings and Thanks!
Click to expand...

Hope my post has helped somewhat.
Volker
Click to expand...

Andre
 
Back
Top