473,836 Members | 2,180 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

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

I've been looking for a new IT position, and so far, the majority of
work with respect to the Windows platform is C#/.Net, with some vb.net
requests every so often. Even many of the C++/MFC/ATL position are ones
in which the companies are looking to migrate this to C# and .Net. I
have NOT even seen one position requesting C++/CLI, let alone any
recruiters who have even heard of it!

I can understand those companies looking to create new applications
looking to start with C#, since it is the new trendy language and one
made specifically for .net, but I would think those looking to migrate
their C++/Win32/MFC/ATL stuff, would be looking at the new and improved
C++/CLI to migrate those portions which make sense to integrate .net.

Instead, I've mostly seen the following types of positions with respect
to C++ on Windows:

1) New apps with C#/.Net requested, and some vb.net only
2) Port all native C++ apps to C#/.Net
3) Stick with native C++, with no .Net at all

Like I mentioned, I can understand 1) since if your going to create new
..Net stuff, might as well use the language built specifically for it.
3) I can understand, since if you have native stuff already that is
working well for you, and especially if its apps with performance and
portability in mind, there is no reason to go .net.

2) though, is what I think is nuts! Looks like some companies have
bought into the .net hype, and are under the notion that they need to
convert their native C++ apps completely to a C# one. Sadly, they don't
seem to know that they can use C++/CLI to extend and preserve their
existing native C++ code. C++/CLI is the perfect candidate for this
type of migration, yet no one seems to be aware of it!

I can only conclude a few things: 1) C++/CLI came too late. This should
have been the first language to come out, instead of the horrendous
managed C++. 2) Microsoft has done a lackluster job of marketing
C++/CLI. 3) My feeling is that the hardcore C++ programming shop could
care less about .Net, and furthermore, I think there is quite some
resistance about a .Net extended language of C++. Just read some of the
newsgroups like comp.lang.c++ or comp.lang.c++.m oderated.

Its sad to see this, given all the investment put into C++/CLI, as well
as the fact that two of my favorite C++ authors, namely Stan Lippman and
Herb Sutter, put a lot of work into this, yet it seems the marketplace
is ignorant of, and maybe even resistent to it.

But I think C++/CLI may wither away, or comprise a very small niche. I
think the best thing to do is either stick with C#/.Net (or vb.net) if
your going to do Windows now and in the future, and for native C++,
either work as a maintence programmer if your on the Windows platform,
or move to a Unix/Linux environment where most of the new and cutting
edge stuff involving C++, as well as C is going on.

-Don Kim
Mar 2 '06
81 4464
> 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
Mar 8 '06 #51
Ajay Kalra wrote:
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
Mar 8 '06 #52

"Shawn B." <le****@html.co m> wrote in message
news:Ok******** *****@TK2MSFTNG P15.phx.gbl...
|> | 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.
Mar 8 '06 #53

"Shawn B." <le****@html.co m> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..
|> 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 GetLastWin32Err or after each call, this
behavior cannot be switched off, while in PInvoke interop you can set a flag
(SetLastErrorCo de=false) to turn this off.

Willy.



Mar 8 '06 #54
>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.
------
Ajay Kalra
aj*******@yahoo .com

Mar 8 '06 #55
In article <On************ **@TK2MSFTNGP10 .phx.gbl>,
tk*********@yah oo.com says...
Jerry Coffin wrote:
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?


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.

--
Later,
Jerry.

The universe is a figment of its own imagination.
Mar 8 '06 #56
> 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
Mar 8 '06 #57
> 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/is...5/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
Mar 8 '06 #58
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.

-------
Ajay Kalra
aj*******@yahoo .com

Mar 8 '06 #59
>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
Mar 8 '06 #60

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

175
11539
by: Sai Hertz And Control Systems | last post by:
Dear all, Their was a huge rore about MySQL recently for something in java functions now theirs one more http://www.mysql.com/doc/en/News-5.0.x.html Does this concern anyone. What I think is PostgreSQL would have less USP's (Uniqe Selling Points
14
2097
by: ccdetail | last post by:
http://www.tiobe.com/index.htm?tiobe_index Python is the 7th most commonly used language, up from 8th. The only one gaining ground besides VB in the top 10. We're glad, our app is written in python. It's free at http://pnk.com and it is a web timesheet for project accounting
0
9810
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
9656
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
10821
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
10527
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
0
9358
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
7774
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
6975
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
5812
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
2
4001
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.