Is C++/CLI gaining any traction???

[Stephen Howe]

There are different sectors in software market.

I know that and your concerns are valid ones.
But they have been addressed some time ago.
Tools like Dephi, VB6 are RAD enviromnments and are suitable for rapid
development of Win32 applications.
Highly skilled developers are not required to use these.
They are very suitable for building dialog boxes etc, quickly.
For Visual C++, as good as the tools are, they have never been RAD.

In contrast .NET means a whole new learning curve of the Framework to
learn - nothing to do with RAD development at all, just MS's design for
..NET.

You can still find tailors who sew by hand and make a work
of art clothes. However, you know by yourself where the
money is now.

Yes. see above.

That is not why. You are confusing RAD tools with .NET environment.
Why not use the RAD tools for Win32 environment?
That meets your productivity concerns _WITHOUT_ all this .NET baggage to
learn.

Stephen Howe

 

[Tom Serface]

Except if you already "know" C++ then you don't have to learn C# to do the
migration. I know that C# has a lot of cool tools that makes it compelling,
but the programming part isn't any easier (same libs, etc.). I hope the
C++/CLI platform gets the same level of tools in an upcoming release to make
it as interesting, but it is nice not having to learn another syntax just to
do the same things.

This is especially true for those of us who have to live in both worlds
(native and managed).

Tom

 

[Shawn B.]

4. C++/CLI does not have any advantage over C# and vice versa.

This mostly might be true. But, I wrote a CPU simulator in C# and wrote it
again in C++/CLI. Guess what? The C++/CLI binary was 12k (C# was 85K) and
while the C# version can execute something like 4.3 million "virtual" cycles
(emulate 4.3 MHz on a 2.2 GHz AMD 64-bit with 1GB RAM) the C++/CLI version
can execute 9.9 million "Virtual" cycles (9.9MHz)... though I think native
C++ can do better, and better yet, I wrote the same thing in win32 assembly
and it performed even better).

My point is that the C++/CLI produces better code than the C# compiler does,
obviously. Its not secret. The syntax is funky, but for my purposes, it
suits my well.

Another thing with C++/CLI, I recently rewrote the System.Console class to
include support for text-user-interfaces and had to do some serious interop.
I first did this in C# but kept having problems with translating the API's
and after 2 weeks something still wasn't working correctly and I couldn't
figure out what it was. I switched to C++/CLI and took me just a few
minutes to up and running (from scratch). They P/Invoke capabilities are
far superior in C++/CLI than they are in C#.

Some of my performance critical stuff I prefer to be inlined. I don't trust
the JIT to inline anything, when there's math involved (or a some
conditional statement or loop) it won't JIT most of the time (if it exceeds,
what they say, 32 bytes). C++/CLI is more likely to inline such code and,
at the very least, you can still use #define macros.

For the most part, these "little" things don't add up. I write business
applications all day (since mid-2001) in C#/ASP.NET and Windows Services/C#
among many other things. I won't give up C# in this environment for the
world, it performs really well. Much much better than VB6. But for certain
exotic things, clearly C++/CLI is the way to go even though you're main
performance limitation is the JIT and runtime. But that's an evil I'm
mostly willing to live with.

Thanks,
Shawn

 

[Jerry Coffin]

[ ... ]

Moreover, industry wants to make average desktop application
as cheap as possible and as fast as possible. That's why
some kind of managed infrastructure is inevitable for pure
economical reasons.

Pardon my being blunt, but BULLSHIT! You're missing the
crucial link here: for this to be anywhere close to
correct, you need to show that a managed infrastructure
actually contributes to the ability to create desktop
applications more efficiently.

So far, that's just not the case. Even if it becomes
clear at some point that a managed framework really is
the way to go, that doesn't mean anything about the
quality of Microsoft's current tools to produce code to
run under their current framework.

About 200 years ago the Luddites claimed the same thing: "we
don't need no stinky new machines!". They were highly
skilled, highly paid and worked primarily by hands. Workers
who used machines were uneducated, poorly trained and
underpaid. However, with machine's help one uneducated
worker could produce ten times more textile than whole team
before for the same period. The product was of slightly
lesser quality than before, however it is quantity and speed
that won, after all.

I've pointed out repeatedly that VC++ 6 has better
productivity than the newer tools. You're replied by
pointing out that at least for some dialogs, the newer
environments have prettier, antialiased, fonts.

If we were to look at this in terms of more physical
tools, VC++ 6 is an ugly old radial arm saw (though it
does have laser guidance) -- and you're advocating
replacing it with a beautiful hand miter box because the
back saw has beautiful brass inlays!

Even your fellow advocate, Tom Serface, has admitted that
with the newer environment, "I've learned to do more
things manually."

To make a long story short, YOU are the Luddite here!

 

[Jerry Coffin]

[ ... ]

I'm sorry if I contributed a little bit of flame here. What
I'm trying to say is that besides technical reasons (which
are discussed most by developers) there are economical ones,
too. Quite often developers argue about merits of
language/technology and forget to consider economical
implications. Technologies like former VB and .NET/Java are
not there because of trendiness or fashion. Software
industry grows; it requires more developer, faster
development cycle and more complex software. At some point
it's impossible (or not worthwhile) to gain new qualities
with older/expensive tools.

You're starting from a fundamentally mistaken and false
premise: that it's more efficient and cheaper to produce
code with the newer tools.

Once you realize that's false, your entire argument
implodes.

 

[Willy Denoyette [MVP]]

|> 4. C++/CLI does not have any advantage over C# and vice versa.
|
| This mostly might be true. But, I wrote a CPU simulator in C# and wrote
it
| again in C++/CLI. Guess what? The C++/CLI binary was 12k (C# was 85K)
and
| while the C# version can execute something like 4.3 million "virtual"
cycles
| (emulate 4.3 MHz on a 2.2 GHz AMD 64-bit with 1GB RAM) the C++/CLI version
| can execute 9.9 million "Virtual" cycles (9.9MHz)... though I think native
| C++ can do better, and better yet, I wrote the same thing in win32
assembly
| and it performed even better).
|

Well I have to disagree, others -
http://www.grimes.demon.co.uk/dotnet/man_unman.htm) and I have run numerous
benchmarks and the difference between both C# and C++ varies between + and -
5%, that means sometime C# produces 'better' code other times it's C++/CLI
which is a bit faster. But in general the differences are nill. After all
the C# team has been using the C# compiler since day one (they build the
framework library) so they are more expirenced in generating IL.

| My point is that the C++/CLI produces better code than the C# compiler
does,
| obviously. Its not secret. The syntax is funky, but for my purposes, it
| suits my well.

Any evidence to prove this claim? MSFT PM's have said many times before that
they won't care about optimizing IL, and have stated that over-optimizing IL
may disturb the JIT and produce worse results at the native code level,
really, the optimizer is the JIT compiler.
|
| Another thing with C++/CLI, I recently rewrote the System.Console class to
| include support for text-user-interfaces and had to do some serious
interop.
| I first did this in C# but kept having problems with translating the API's
| and after 2 weeks something still wasn't working correctly and I couldn't
| figure out what it was. I switched to C++/CLI and took me just a few
| minutes to up and running (from scratch). They P/Invoke capabilities are
| far superior in C++/CLI than they are in C#.
|

PInvoke is PInvoke,so, I guess you mean C++ interop. Well, whenever you
transition from managed to unmanaged, you take the same performance hit,
whether you use C++ interop (aka IJW) or PInvoke, more, the exact same code
is used inside the CLR, just write some small samples using both and single
step through the code when calling into unmanaged from managed, watch the
code path you'll see they are exactly the same, the reason is simple, there
is no difference at run-time, what's executed is native code and the CLR
doesn't have the slightest idea what tool was used to build the IL, all he
knows is that there is a transition from managed code into unmanaged and he
has to perform some tasks like signaling the GC that a thread leaves the
CLR, so he knows that he cant return when the GC runs. Other things like a
security walk must be done (can partly be suppressed), an unmanaged
exception frame must be created on the stack etc. The only difference is
that you have more control over the argument marshaling when using C++
interop (IJW ) which can give you some advantage if you really pay attention
to it, but for most of the data types there isn't that much to gain.


| Some of my performance critical stuff I prefer to be inlined. I don't
trust
| the JIT to inline anything, when there's math involved (or a some
| conditional statement or loop) it won't JIT most of the time (if it
exceeds,
| what they say, 32 bytes). C++/CLI is more likely to inline such code and,

You mean it won't inline do you? Well, the same is true for C++/CLI as it
generates IL just like all others managed compiler, the inlining is done by
the JIT compiler not by the IL.


Willy.

 

[Alex Blekhman]

You're starting from a fundamentally mistaken and false
premise: that it's more efficient and cheaper to produce
code with the newer tools.

Is it not? If you're talking about overall investments in IT
and software development in particular, then I will agree
with you: it constantly grows. However, today you get more
value for the same money than before. I see software
development somewhat akin to hardware: average PC always
costs about $1000, but its capability grows.

 

[Ajay Kalra]

You cannot and should not compare SW development with hardware. There
is significant investment in software developers doing the work. The
human cost and experience alone prohibits going blindly to new tools,
regardless of how productive one may perceive these are. There are
other significant costs: QA, training, transition, deployment etc. All
this is real. As opposed to Hardware upgrade for developers, which is
essentially meaningless. These two could not be further apart.

 

[Ajay Kalra]

Willy,

Excellent. I had missed this discussion on Richard's site as well.

 

[Shawn B.]

| Some of my performance critical stuff I prefer to be inlined. I don't

trust
| the JIT to inline anything, when there's math involved (or a some
| conditional statement or loop) it won't JIT most of the time (if it
exceeds,
| what they say, 32 bytes). C++/CLI is more likely to inline such code
and,

You mean it won't inline do you? Well, the same is true for C++/CLI as it
generates IL just like all others managed compiler, the inlining is done
by
the JIT compiler not by the IL.

There are many MS developers that discuss compiler optimizations in Visual
C++ 2005 and they make no secret that the compiler actually does do more
agressive inlining at compile time rather than leaving it to the JITer. It
also does whole application optimizations and profil guided optimizations.
All of which the C# compiler does not do at all. Do a google, there's
plenty of support; I'm not just pulling this out of my rear.

Further more, on my CPU emulator, when I converted it into C++/CLI and
turned on/off the inlining optimization options, the runtime performance of
the virtual CPU jumps drastically when inlining optimzations are turned on,
when off, they are more inline (no pun intended) with the performance
characteristics of C#. I'm not saying C++/CLI is better or worse than C#,
I'm simply saying on exceptionally performance needy projects I create (I've
only created two, everything else is in C#) the C++/CLI compiler make a
noticable difference in performance when I run the application. Clearly,
there is something in the C++ compiler that is doing something much smarter
than what the C# compiler does.


Thanks,
Shawn

 

[Shawn B.]

PInvoke is PInvoke,so, I guess you mean C++ interop. Well, whenever you

transition from managed to unmanaged, you take the same performance hit,
whether you use C++ interop (aka IJW) or PInvoke, more, the exact same
code
is used inside the CLR, just write some small samples using both and
single
step through the code when calling into unmanaged from managed, watch the
code path you'll see they are exactly the same, the reason is simple,
there
is no difference at run-time, what's executed is native code and the CLR
doesn't have the slightest idea what tool was used to build the IL, all he
knows is that there is a transition from managed code into unmanaged and
he
has to perform some tasks like signaling the GC that a thread leaves the
CLR, so he knows that he cant return when the GC runs. Other things like a
security walk must be done (can partly be suppressed), an unmanaged
exception frame must be created on the stack etc. The only difference is
that you have more control over the argument marshaling when using C++
interop (IJW ) which can give you some advantage if you really pay
attention
to it, but for most of the data types there isn't that much to gain.

Maybe so, but fighting this crap in C# for weeks and getting it right in
C++/CLI after only hours of trying, one can argue, performance gain or not,
there was certainly a productivity gain. Anyway, I was watching one of the
PDC05 videos on sitestream.com the other day and they were talking about
some of performance enhancements. They specifically mentioned that for
certain data types, such as int, long, byte, string, you know, the basics,
they interop transitioning has been greatly improved and optimized. I was
left with the distinct impression that 1) it wasn't optimized in previous
managed C++ compiler, and 2) it is more optimized than the P/Invoke in C#.
So, again, there possibly is a performance benefit whether significant or
not in the scheme of things, I don't know, but the point is they made some
improvements above and beyond what we had before.


Thanks,
Shawn

 

[Don Kim]

On the same note, Eric Gunnerson moved some time ago from C# to DVD
maker group to develop a new application. Guess what they end up using
for developing a brand new application(no legacy code): NOT .Net (I
think its C++). That said a lot about MSFT's own embrace to .Net.

Indeed. But as the famous phrase states, "if you forget the past, you
are doomed to repeat it". I can cleary recall during the java hype days
of the late 90s, when a company (I think it was Corel?) stupidly decided
to REWRITE (I emphasize this, because it was a complete line by line
rewrite) their office application to java. At least Winforms has some
decent performance, not to mention the hardware improvements since then,
but back then was when the gawd aweful AWT was the standard, and Swing
(which still sucked) was just comming in. If I recall, this literally
bankrupted the company.

I doubt (though you never know) that a company would give into hype in
such an all embracing and detrimental manner, but if you buy into some
new trend w/out careful evaluation of when such a trend will be useful,
some pretty bad outcome will happen. This goes for the developers as
well, who stake their career chasing after the hottest trends (SOAP
anyone? What happnened to all the hype about SOAP/web services?!),
instead of the fundamentals and broad knowledge.

-Don Kim

 

[Willy Denoyette [MVP]]

|> | Some of my performance critical stuff I prefer to be inlined. I don't
| > trust
| > | the JIT to inline anything, when there's math involved (or a some
| > | conditional statement or loop) it won't JIT most of the time (if it
| > exceeds,
| > | what they say, 32 bytes). C++/CLI is more likely to inline such code
| > and,
| >
| > You mean it won't inline do you? Well, the same is true for C++/CLI as
it
| > generates IL just like all others managed compiler, the inlining is done
| > by
| > the JIT compiler not by the IL.
| >
| There are many MS developers that discuss compiler optimizations in Visual
| C++ 2005 and they make no secret that the compiler actually does do more
| agressive inlining at compile time rather than leaving it to the JITer.
It
| also does whole application optimizations and profil guided optimizations.

Right, but they are talking about VC8 ISO/C++ not about C++/CLI, we are
talking about C++/CLI don't we?
All this is NOT applicable to managed code! Inlining is done at the "native"
code level, how would you do this at the IL level?.
Note also thet inlining is very restricted in .NET, only small pieces of
code are inlined, that is the method must be < 32 bytes of IL byte code,
must not have guarded block (try/catch/finally), cannot have complicated
constructs like loops, cannot call into unmanaged code etc...

| All of which the C# compiler does not do at all. Do a google, there's
| plenty of support; I'm not just pulling this out of my rear.
|
No but you are talking about something alse.

| Further more, on my CPU emulator, when I converted it into C++/CLI and
| turned on/off the inlining optimization options, the runtime performance
of
| the virtual CPU jumps drastically when inlining optimzations are turned
on,
| when off, they are more inline (no pun intended) with the performance
| characteristics of C#. I'm not saying C++/CLI is better or worse than C#,
| I'm simply saying on exceptionally performance needy projects I create
(I've
| only created two, everything else is in C#) the C++/CLI compiler make a
| noticable difference in performance when I run the application. Clearly,
| there is something in the C++ compiler that is doing something much
smarter
| than what the C# compiler does.

I've run hundreds of benchmarks comparing both C#, C++/CLI, differences
obtained between different runs of the benchmarks are neglectable.
And the reason is simple, IL is translated into native code, and the IL
level there is little or nothing to optimize without the risk to produce
unverifiable code. I remember Ronald Laeremans (PM VS C++ team) said this:
"we are focusing on the JIT to perform optimizations" some time ago, not on
the IL level", that's why the C++ back-end compiler team owns the JIT
compiler.
Believe me, both C# and C++/CLI look more like a one-egg twin at run-time.

Willy.

 

[Willy Denoyette [MVP]]

|> PInvoke is PInvoke,so, I guess you mean C++ interop. Well, whenever you
| > transition from managed to unmanaged, you take the same performance hit,
| > whether you use C++ interop (aka IJW) or PInvoke, more, the exact same
| > code
| > is used inside the CLR, just write some small samples using both and
| > single
| > step through the code when calling into unmanaged from managed, watch
the
| > code path you'll see they are exactly the same, the reason is simple,
| > there
| > is no difference at run-time, what's executed is native code and the CLR
| > doesn't have the slightest idea what tool was used to build the IL, all
he
| > knows is that there is a transition from managed code into unmanaged and
| > he
| > has to perform some tasks like signaling the GC that a thread leaves the
| > CLR, so he knows that he cant return when the GC runs. Other things like
a
| > security walk must be done (can partly be suppressed), an unmanaged
| > exception frame must be created on the stack etc. The only difference is
| > that you have more control over the argument marshaling when using C++
| > interop (IJW ) which can give you some advantage if you really pay
| > attention
| > to it, but for most of the data types there isn't that much to gain.
|
| Maybe so, but fighting this crap in C# for weeks and getting it right in
| C++/CLI after only hours of trying, one can argue, performance gain or
not,
| there was certainly a productivity gain. Anyway, I was watching one of
the
| PDC05 videos on sitestream.com the other day and they were talking about
| some of performance enhancements. They specifically mentioned that for
| certain data types, such as int, long, byte, string, you know, the basics,
| they interop transitioning has been greatly improved and optimized. I was
| left with the distinct impression that 1) it wasn't optimized in previous
| managed C++ compiler, and 2) it is more optimized than the P/Invoke in C#.
| So, again, there possibly is a performance benefit whether significant or
| not in the scheme of things, I don't know, but the point is they made some
| improvements above and beyond what we had before.
|

Well, you need to take care about marshaling yourself, and oh... don't
forget to pin and un-pin when passing managed types to unmanaged, this is
something you don't have to care about when using PInvoke (in C# or C++).
Note also that the interop performance in managed C++ (ME C++) was bad (and
worse than C# PInvoke), this has greatly improved in C++/CLI, where it's now
on par with C# or C++ PInvoke interop. The reason for this is that they have
unified the interop path in V2 of the framework, both C# or C++/CLI go from
managed to unmanaged using the same CLR generated thunk(s), It just needs a
small piece of code and a native code debugger to watch this.
Note that, here I'm comparing C# PInvoke to IJW. IJW is mixed mode interop,
that means that the caller (managed) and callee (unmanaged) are in the same
assembly.
However, when calling from managed into a unmanaged accross DLL boundaries ,
the performance of C# PInvoke is better than the C++ interop, the reason for
this is that C++ interop calls GetLastWin32Error after each call, this
behavior cannot be switched off, while in PInvoke interop you can set a flag
(SetLastErrorCode=false) to turn this off.

Willy.

 

[Ajay Kalra]

I can cleary recall during the java hype days

of the late 90s, when a company (I think it was Corel?) stupidly decided
to REWRITE (I emphasize this, because it was a complete line by line
rewrite) their office application to java.

I do recall this. It made the business news and boosted Sun's stock.

I doubt (though you never know) that a company would give into hype in
such an all embracing and detrimental manner,

I agree but I think its developers who fall for the hype before the
company does.

I recall in one of the summits at Redmond, BillG was asked about why
not making a product which used VB. He had no answer. It was followed
by why not use .Net to make a product. Again he had no answer but he
promised to make sure that would happen. That was ~3 years ago. It
appears .Net to MSFT is same as VB was at least for desktop
applications. I think .Net makes a whole lot of sense for web
applications than desktop. For desktop, it makes sense if you are
writing a new application. Microsoft had earlier suggested that .Net
will now be the only way they will release new API. That was a threat
so that you should move to .Net. That was 3-4 years ago. They have
retreated from it as they found .Net wasnt being adopted as they
expected.

I used .Net (C#) for about a year few months ago. After initial
hesitation, I thought it was very productive. I was actually happy that
I wasnt using C++. No header files, no macros, no STL, no templates,
excellent type safety etc. The transition was difficult, especially
from MFC(very different mindset) but when it finally hit me, I thought
it was good. In my new job, we will migrate from unmanaged(C++) to
managed some time soon and we are still figuring out the performance
issues. Initial research has indicated that performance hit isnt there
(Its a big multi-threaded financial application; eg trading stocks
etc). We will see.

 

[Jerry Coffin]

Is it not?

That's correct -- they're less efficient, so they're more
expensive to use.

If you're talking about overall investments in IT
and software development in particular, then I will agree
with you: it constantly grows. However, today you get more
value for the same money than before. I see software
development somewhat akin to hardware: average PC always
costs about $1000, but its capability grows.

I'm talking about the fact that there are simply a lot of
things that ClassWizard made quick and simple that the
newer tools require the user to do by hand so they take
more time and effort.

I'm not talking about investments in software up front --
I'm talking about the ongoing cost of the development
itself. It's slower and clumsier, so it's more expensive.

A hardware upgrade is a one-time cost, so you can
amortize it over its life. When you look at things in
terms of amortized cost vs. productivity, it's easy to
figure out whether a particular upgrade makes sense.

The problem is that in this case, we're talking about the
equivalent of taking your 3.4 GHz P4 that you paid $1500
for, and trying to justify replacing it with a 266 MHz P2
that costs $10,000 instead.

In this case, the cost of the tools and/or hardware to
run them on is almost irrelevant -- what's relevant is
that the tools get in the way of getting the job done,
and there's no amount of hardware upgrade that makes up
for the fact that I have to do 20 minutes of hand editing
instead of clicking one button one time to get the job
done.

 

[Shawn B.]

writing a new application. Microsoft had earlier suggested that .Net

will now be the only way they will release new API. That was a threat
so that you should move to .Net. That was 3-4 years ago. They have
retreated from it as they found .Net wasnt being adopted as they
expected.

Lets be corrected on this. They haven't retreated from anything. New API's
are primarily in .NET and available to unmanged code by using mixed mode
programming in C++/CLI as they recomment. WSE2 is a .NET API. Windows
Presentation Foundation (Avalon) is a .NET API. In fact, after looking at
the upcoming stuff on Microsoft's website, I can see, they are pretty vocal
about the new API's being .NET first.

I don't know whether .NET is the future or not. I know I get paid very well
to be a .NET developer since 2001. Its what I know. There are plenty of
job oppurtunities for .NET developers in general. Its thriving. Lots of
businesses are using .NET. There are reasons why not to. But companies
like Microsoft cannot simply just rewrite Windows and Office or Exchange and
SQL Server in .NET. They have a legacy code base to maintain that is
well-invested. I suspect Office may eventually go .NET but not by way of
rewrite. IJW is probly going to be the leveraging tool in this case. They
are going out of their way to integrate .NET into Office and SQL Server.
They must believe in it. If they can't completely rewrite, at least they're
providing hooks for .NET integration.

I think new API's should be native but I can understand why they'd want it
to be .NET. While new functionality can be added to Windows Next and
consumed by .NET on that platform, it would be too much effort to backport
the new Windows functionality to earlier versions of still supported OS's.
With .NET, they can take advantage of the native platform feature internally
on the Windows that supports it, and emulate the feature for those that
don't. Makes sense to me why they would make new API's a .NET API.

However, shrinkwrap software may not be going .NET in droves, but internal
development is increasingly using .NET. I think as our knowledge improves
of the platform so will also the projects using that knowledge follow.


Thanks,
Shawn

 

[Shawn B.]

I've run hundreds of benchmarks comparing both C#, C++/CLI, differences

obtained between different runs of the benchmarks are neglectable.

I've created a real application in both C# and the same in C++/CLI and the
difference was staggering (a CPU emulator for an Apple2 emulator targeting
..NET -- not a business application or service). It was identicle code, not
different in architecture or design. So there we are. So your benchmarks
don't reveal any real benefits, but my real application that I'm doing
something with and have vested over a year in building, actually shows
interesting results. You written a CPU emulator? In my design, there are
hundreds of functions that emulate a CPU instruction. These functions get
called 9 million times per second on an unthrottled emulation (using
C++/CLI). Using C#, and almost identical translation of the code, comipled
in C#, gives me 4 million iterations per socond. Big difference. Clearly,
the C++/CLI compiler is doing something that the C# compiler is not.

Anyway, I refer you to the April 2005 edition of MSDN magazine where Stephen
Toub discusses some of the improvements in the Visual C++ 2005 compiler
http://msdn.microsoft.com/msdnmag/issues/04/05/VisualC2005/ .

I quote an important paragraph (the last paragraph in the optimizations
section):

---------

In an important change for developers using .NET, the Visual C++ 2005
optimizer performs most of the same optimizations when targeting MSIL as it
does when targeting the native platform, though it does so with different
tuning. While the just-in-time (JIT) compiler today analyzes for
optimizations at run time, allowing the C++ compiler to optimize during the
initial compilation can still provide significant performance benefits (the
C++ compiler has much more time to perform its analysis than does the JIT).
The Visual C++ 2005 compiler optimizes managed types for the first time,
performing loop optimizations, expression optimizations, and inlining. There
are places, though, where the compiler can't optimize .NET-based code. For
example, it has problems with strength reduction due to the unverifiability
of pointer arithmetic, and certain code can't be inlined due to the strict
type and member accessibility requirements of the CLR, though it does do
significant analysis for legal inlining opportunities. In addition,
optimizing MSIL introduces the need to make trade-offs concerning what is
presented to the JIT compiler. For example, you wouldn't want to unroll a
loop and expose a plethora of variables to the JIT compiler, whereupon it
would have to perform register allocation (an NP-complete problem). The
Visual C++ team is working through these issues and will have a very
well-tuned optimizing solution by the time the system is released.

--------


This directly contradicts what you've been saying.


Thanks,
Shawn

 

[Ajay Kalra]

I do not agree with you on MSFT's own confidence in organic .Net
growth. Look at Richard's analysis here:

http://www.grimes.demon.co.uk/dotnet/vistaAndDotnet.htm

You will note that MSFT has in fact removed number of services that
depend upon .Net in newer version of Vista. .Net is now relatively
matured and you would expect MSFT to be sort of the leader in accepting
it. IMO, that has not been the case.

My expertise is MFC and I typically post in that newsgroup. I am
surprised that number of people posting there have actually gone up
recently. May not be big deal but it appears some of newer
developers/products are actually going unmanaged.

 

[Shawn B.]

I do not agree with you on MSFT's own confidence in organic .Net

growth. Look at Richard's analysis here:

http://www.grimes.demon.co.uk/dotnet/vistaAndDotnet.htm

You will note that MSFT has in fact removed number of services that
depend upon .Net in newer version of Vista. .Net is now relatively
matured and you would expect MSFT to be sort of the leader in accepting
it. IMO, that has not been the case.

This Grimes article refers to information at was current during PDC03, as
those make up 95% of his references. Second, read the Microsoft website
today and you will see that many of the new .NET API's will be managed only.
Don't believe me? Don't care. But at least take the time to read MS's own
(current) information. I did just last week because this same exact topic
keeps coming up other places and many people read what others have to say
(ala Richard Grimes during PDC03 -- 2 years ago) but I prefer to see what MS
currently says, since they are always changing their mind. Their current
state of mind is that new WinFX API's will be managed. Until they change
this information on the WinFS homepage I'll continue to believe it.


Thanks,
Shawn