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" wrote:
[color=blue]
> 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.[/color]
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.
[color=blue]
> I've got a bit of experience in C++ from about ten years ago
> on Linux.[/color]
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.
[color=blue]
> 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.[/color]
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.
bruno_nos_pam_van_dooren@hotmail.com
Remove only "_nos_pam"
