"Pavel Minayev" <evilone@omen.ru> wrote in message news:adhor6$dqa$1@digitaldaemon.com...
> "OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:adgi89$276q$1@digitaldaemon.com...
>
> > COM is not slow. Even DirectX uses COM and they would never do that if it really were slow. Ofcourse when you use COM to build a remote component to be accessed over the internet that's slow... :) But when you just use a .dll it is fast.
>
> DX doesn't really uses COM to its fullest. It provides
> functions to create DX objects fast, without using the
> slow-as-hell COM/Automation mechanisms (CoCreateInstance
> etc). It does not use dual interfaces, as far as I know.
> It does not use SAFEARRAY and BSTR. Etc etc etc.
>
> Just compare DX VB library (COM!) to DX C++ library (COM?),
> and see the difference in speed...
>

So just say "Automation is slow", not "COM is slow".
Automation is a superset of COM, it's like comparing
C++ to C, they are just not the same thing.
And I agree that automation is slow, but there are
benefits to compensate for this.
DirectX does use CoCreateInstance, it is just
wrapped in a more user-friendly call. However after
you have created the first object all others are
created through calls to this object.


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

"andy" <acoliver@apache.org> wrote in message news:3CFBCFB5.2070304@apache.org...
>
> >
> > COM is not slow. Even DirectX uses COM and they would never do that if it really were slow. Ofcourse when you use COM to build a remote component to be accessed over the internet that's slow... :) But when you just use a .dll it is fast.
> >
>
> And its deprecated.


No it isn't, the whole .net framework is built on it's
foundations. That's just the usual 'Microsoft Marketing
Blabber' (tm). The are not about to deprecate the milions
of lines of code written with COM. Just think of your
excel sheet embedded in your Word document (OLE), all
the Windows Explorer extension, all the ActiveX controls,
allmost all the games written in the last few years,
etcetera, etcetera, etcetera. Ofcourse they do want you
to switch to .net, but that is another story.

--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

> 
> No it isn't, the whole .net framework is built on it's
> foundations. That's just the usual 'Microsoft Marketing
> Blabber' (tm). The are not about to deprecate the milions
> of lines of code written with COM. Just think of your
> excel sheet embedded in your Word document (OLE), all
> the Windows Explorer extension, all the ActiveX controls,
> allmost all the games written in the last few years,
> etcetera, etcetera, etcetera. Ofcourse they do want you
> to switch to .net, but that is another story.
> 

You're right.  I was thinking of MFC.

> --
> Stijn
> OddesE_XYZ@hotmail.com
> http://OddesE.cjb.net
> _________________________________________________
> Remove _XYZ from my address when replying by mail
> 
> 
> 

"Pavel Minayev" <evilone@omen.ru> wrote in message news:ad4d3a$83g$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:ad3pg0$2hgm$1@digitaldaemon.com...
> > The proper way to do it would be to create a variant type, and then have variable parameter lists be passed as arrays of variants.
> So, what about variants?

They're a good idea, I just need to do more work on it.

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:ad5q85$2mv2$1@digitaldaemon.com...
> C# is not interpreted... it's always JIT compiled.
>
> It should in theory be able to be as fast as C++.
>
> Sean

That was the theory with Java JITs, too, but the various semantics of the language seem to have defeated that. For example, arrays are always objects allocated on the heap, and they are always bounds checked. The translation layer needed to interface with C doesn't help. The biggest slowdown is probably the lack of lightweight objects. No support for byte chars hurts. I could go on ... <g>.

Some experiments show that expert Java programmers can approach the speed of C++, but it shouldn't be necessary to be in that top 1% to get fast code.

D has some features which will make it slower than C/C++, and some that will make it faster. It's too soon to tell how on balance it will work out. The neat thing about D is you should be able to get the reliability of Java with the performance of C/C++.

Guys

I wrote an article for CUJ, which Walter helped a little with, that is being published in the September edition. It was entitled "A performance comparison of C# with C, C++, D and Java" which may throw a small amount of light on the subject. Results demonstrate that both C# (sadly) and D (yeah) are very good performers on the Win32 platform, and although one can get C/C++ to outperform, it requires explicit coding to that end (which kind of defeats the purpose, for most scenarios)

Walter, I haven't heard back from the publisher re my forwarding you a pre-print, so assume I cannot. It'll be out in 8 weeks, though ... ;)


"Walter" <walter@digitalmars.com> wrote in message news:ae4ctn$1udb$1@digitaldaemon.com...
>
> "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:ad5q85$2mv2$1@digitaldaemon.com...
> > C# is not interpreted... it's always JIT compiled.
> >
> > It should in theory be able to be as fast as C++.
> >
> > Sean
>
> That was the theory with Java JITs, too, but the various semantics of the language seem to have defeated that. For example, arrays are always
objects
> allocated on the heap, and they are always bounds checked. The translation layer needed to interface with C doesn't help. The biggest slowdown is probably the lack of lightweight objects. No support for byte chars hurts.
I
> could go on ... <g>.
>
> Some experiments show that expert Java programmers can approach the speed
of
> C++, but it shouldn't be necessary to be in that top 1% to get fast code.
>
> D has some features which will make it slower than C/C++, and some that
will
> make it faster. It's too soon to tell how on balance it will work out. The neat thing about D is you should be able to get the reliability of Java
with
> the performance of C/C++.
>
>

"andy" <acoliver@apache.org> wrote in message news:3D03D095.6090807@apache.org...
>
> >
> > No it isn't, the whole .net framework is built on it's
> > foundations. That's just the usual 'Microsoft Marketing
> > Blabber' (tm). The are not about to deprecate the milions
> > of lines of code written with COM. Just think of your
> > excel sheet embedded in your Word document (OLE), all
> > the Windows Explorer extension, all the ActiveX controls,
> > allmost all the games written in the last few years,
> > etcetera, etcetera, etcetera. Ofcourse they do want you
> > to switch to .net, but that is another story.
> >
>
> You're right.  I was thinking of MFC.
>


And good riddance!   ;)


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail