Re: Is There Any Reason to Even Use VC++ Anymore?

I never did any benchmarks, so I was basing my statement on other reports.
Thus I believe your findings more than what I've read (even though,
ironically, all I've done is read what you've said in saying this...lol). So
speed is not a selling point.

Still, I prefer to use C++ over C#, probably just because I prefer (am more
familiar with) the syntax. And, I'm afraid of seeing this pop up one day on
the MS website:

"MS has deprecated C++ in favor of C#". <shiver>

[==P==]

"Willy Denoyette [MVP]" <willy.denoyette@xxxxxxxxxx> wrote in message
news:%23zRxHf%239FHA.3884@xxxxxxxxxxxxxxxxxxxxxxx
> Sure, for those who believe this nonsense. Those who ran some benchmarks
> know that there is almost no difference, for some specific cases C++/CLI
> is a bit faster and in other cases C# is a bit faster. This is quite
> normal if you know that both front-end compilers emit MSIL and the bulk of
> the optimizations are done at JIT compile time. Sure the C++ compiler can
> spend some extra time to optimize MSIL, while the C# compiler is more time
> constrained, but in reality there is very little that can be done at the
> MSIL level. Note also that a great deal of the code that gets executed in
> a real world application comes from the FCL which is written in C#.
> Believe me, performance is not C++/CLI's selling point.
>
> Willy.
>
> "Peter Oliphant" <poliphant@xxxxxxxxxxxxxxxx> wrote in message
> news:endR7zp9FHA.2676@xxxxxxxxxxxxxxxxxxxxxxx
>> I've heard VS C++.NET can run from 6-10 times FASTER than VS C#.NET.
>> That's a pretty good selling point right there... : )
>>
>> [==P==]
>>
>> "Herby" <prmarjoram@xxxxxxxxx> wrote in message
>> news:1133452860.750447.171420@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>> We have chosen C++\CLI as our current source code base is in C++ and
>>> provides a clear migration path.
>>> Its also a benefit for us to be able to use mixed mode using both the
>>> un-managed and managed heap in the same application/function.
>>> You could almost think of the syntax extensions almost independent of
>>> .NET. Just can now work with a garbage collector etc.
>>>
>>
>>
>
>


.

Relevant Pages

  • Re: Is There Any Reason to Even Use VC++ Anymore?
    ... for those who believe this nonsense. ... Those who ran some benchmarks ... you know that both front-end compilers emit MSIL and the bulk of the ... Sure the C++ compiler can spend ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Something on CVF 6.6C
    ... > while Intel keeps saying that there is no market for MSIL. ... meant insufficient market for yet another Fortran compiler to generate MSIL, ... I don't believe those vendors ...
    (comp.lang.fortran)
  • Re: .Net applications, not optimized for CPU at all?
    ... Both Java VM and MSIL are logically stack machines. ... while the MSIL instructions aren't. ... This implies that all the usual compiler tricks can be applied. ...
    (borland.public.delphi.non-technical)
  • Re: Polyhedron Benchmarks 2004
    ... > I have just revised the compiler comparison charts at www.polyhedron.com. ... > The execution time benchmarks have been substantially revised, ... > Windows XP Pro and Red Hat 9.0. ...
    (comp.lang.fortran)
  • Re: Yet Another Lisp Performance Thread
    ... commercial compilers is using them to compile a competitive compiler. ... As far as benchmarks go, there are lies, damn lies, statistics, and ... My original post was actually intended to show that Lisp can be ... work the JPEG encoder, the Lisp program can pick up even more speed. ...
    (comp.lang.lisp)