473,836 Members | 2,227 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
>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.


Okay, after re-reading it. I don't know. Everyone takes one aspect of a
situation and doomday-speaks it. I don't believe MS is having problems
believing in .NET. Just read every single microsoft programmers blog and it
seems every employee has nothing but passion and faith for .NET. There
could well be far too many other issues involved than just whether something
is .NET or not. That's just an aspect and I don't believe it is
representative.

However, on their current WinFS homepage, they are pretty clear that the
newer API's will be .NET based. Not just there, but all over the Microsoft
developer blogs they are constantly talking about it. I think they released
they need to increment their way to change rather than do it all at once. I
agree. That's why Office hasn't been completely rewritten.

Anyway, Delphi programmers and C++ programmer have a major hesitation to
migrate to .NET and their arguments are two-fold: 1) .NET doesn't perform as
well as native code and 2) Microsoft hasn't rewritten any of their
applications to use .NET so they must not believe in it. I don't think
either of which are good enough reasons to avoid it. .NET performs very
well for our high-volume applications that get millions of transactions per
day. And while they haven't rewritten any of their major revenue-generating
products in .NET (why should they, they've millions invested in bug fixes
stability and enhancements already) it doesn't mean we shouldn't. Like I
said, shrinkwrap software may not be written in .NET but many internal and
server-type applications are already being done in .NET or will be soon.

Some people just want excuses and will use any they can to support their
bias. Me? I think .NET is quite capable of supporting about 90% of all the
applications that would need to be created... for numerical-heavy crunching
use a better tool, FORTRAN or C++, for everything else, C# is sufficient.
CPU clock-cycle performance isn't a necessary argument when the applications
spends 98% of its time waiting for the user to click or type, or when the
bottle neck is the network/sql server load combo.
Thanks,
Shawn
Mar 8 '06 #61
In article <Ou************ **@tk2msftngp13 .phx.gbl>,
le****@html.com says...

[ ... ]
Anyway, Delphi programmers and C++ programmer have a major hesitation to
migrate to .NET and their arguments are two-fold: 1) .NET doesn't perform as
well as native code and 2) Microsoft hasn't rewritten any of their
applications to use .NET so they must not believe in it. I don't think
either of which are good enough reasons to avoid it.
That depends. Just for a quick example, I recently did a
quick test re-compiling some code to run as C++/CLI. This
particular piece of code just does number crunching on
some big matrices, so it didn't take much to make it
compile.

The result is basically disastrous. In C++, the code is
slow enough to be mildly annoying. The number crunching
normally takes anywhere from a few seconds up to around
15 or 20 minutes. Much more than that, and you run out of
memory (at least on a 32-bit OS).

Under the CLR, a fairly small dataset that takes a couple
of minutes to process with native code ran for a couple
of hours before I gave up and killed it -- I have no idea
how long it would have taken to actually finish. Just for
run, I once converted (an older version of) the code to
Java, and while the performance dropped, it wasn't nearly
this bad -- performance dropped by something like 7:1 or
so, but this was more like 30:1 (and maybe worse).
.NET performs very
well for our high-volume applications that get millions of transactions per
day.
The minute somebody starts talking about transactions per
day, it's virtually a certainty that you're dealing with
an I/O bound application. Talking about language
performance in I/O bound applications is basically
meaningless.
Some people just want excuses and will use any they can to support their
bias. Me? I think .NET is quite capable of supporting about 90% of all the
applications that would need to be created... for numerical-heavy crunching
use a better tool, FORTRAN or C++, for everything else, C# is sufficient.
CPU clock-cycle performance isn't a necessary argument when the applications
spends 98% of its time waiting for the user to click or type, or when the
bottle neck is the network/sql server load combo.


So, basically, your argument is that C# can provide good
enough performance, at least for situations where
performance just doesn't matter (at all).

I'm always left with a question though: given that C++ is
already known, and even according to the C# advocates
provides substantially superior performance, what real
advantage does C# provide to make up for its obvious
shortcomings?

MS's tools have deteriorated so development (at least for
desktop apps) is clearly slower and clumsier. All of the
..NET stuff strikes me as being a lot like the VB used to
be, where everything tried to be forms based, whether it
made any sense or not, so at least without a lot of extra
work, everything ends up looking cookie-cutter generic.
The runtime performance isn't exactly something you can
get excited about.

I'm may be a little to young (and the wrong gender) to
play the part to perfection, but "Where's the meat?"

--
Later,
Jerry.

The universe is a figment of its own imagination.
Mar 8 '06 #62
Hi Ajay,

Most of this is hearsay, but from what I understand they actually went back
to Longhorn and removed a lot of the .NET they were trying to use because
they were having performance problems. So, from what I understand much of
Vista, and Office 12 for that matter, is still unmanaged code. I believe in
the effort to make software more trustworthy, but it seems that we are all
not so eager to do it at the cost of performance or size. I think that
curve may change over time.

Tom

"Ajay Kalra" <aj*******@yaho o.com> wrote in message
news:11******** **************@ i40g2000cwc.goo glegroups.com.. .
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 #63
Don Kim wrote:

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++.


Microsoft destroyed Managed C++ with the DLL Initialization bug. It just
happened to occur ( hardy har har ) and give C# and VB .NET a four year
head start in .NET programming. Given that head start, what do you
suppose would happen to companies when it came to moving their C++ apps
to .NET ? And please do not tell me that MS did not have a strong
interest in promoting C# over C++.
Mar 9 '06 #64
"Ajay Kalra" <aj*******@yaho o.com> wrote:

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.


On the other hand, the Media Center app in Windows Media Center Edition is
all written in .NET. It's not my favorite Microsoft application, but it is
evidence that a .NET front-end with a clever back-end can do some pretty
neat things.
--
- Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.
Mar 9 '06 #65
>On the other hand, the Media Center app in Windows Media Center Edition is
all written in .NET. It's not my favorite Microsoft application, but it is
evidence that a .NET front-end with a clever back-end can do some pretty
neat things.


And be just as buggy as any other program ;)

Dave
Mar 9 '06 #66
Edward Diener wrote:
Don Kim wrote:

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++.
Microsoft destroyed Managed C++ with the DLL Initialization bug.


I should have said the Loader Lock bug, as that is its more popular name.
It just
happened to occur ( hardy har har ) and give C# and VB .NET a four year
head start in .NET programming. Given that head start, what do you
suppose would happen to companies when it came to moving their C++ apps
to .NET ? And please do not tell me that MS did not have a strong
interest in promoting C# over C++.

Mar 9 '06 #67


"Shawn B." <le****@html.co m> wrote in message
news:eN******** ******@TK2MSFTN GP12.phx.gbl...
|> 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.
|

You keep refering to the one and only application, and based on that you
claim that C++/CLI is much faster than C# (twice as fast!) while this
http://www.grimes.demon.co.uk/dotnet/man_unman.htm proves it's not the case,
but I guess this isn't of any value for you.
I can't comment on what you have done without seeing any code, you might be
calling into native code or using unsafe constructs (bypassing security
walks) which is what IJW does, while in C# this isn't true by default. If
you want to compare both you need to turn of Securty checks in C# as well,
or you need to compile your stuff using /clr:safe , if this isn't possible
because the compiler complains about mixed mode stuff, then we are not
talking about the same thing really.

I have run several benchmarks (hundreds), just like many others, and all I
can say is that the differences are minimal, sometimes C# wins and sometime
C++/CLI wins, sometimes C# produces better IL sometimes C++ does, but the
differences at run-time are minimal (+- 5%), that's all. Do you think that
the C# team isn't able to emit the same optimized IL as the C++/CLI
front-end, do you really believe both teams are competitors? Would they
build the Framework (and Most of WinFX(WPF and WCF..) using C# if C++/CLI
was that better performing?

| 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/ .
|

This guy is a Technical Editor for MSDN Magazine, his job is to 'spread the
message' and promote MSFT products, and he did a great job. But sorry, I
don't believe everything I read, especially when it's possible to verify
what there is written.
| 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.
|

Realy? Are you basing your findings on a piece written by a technical
editor, not a member of the C++ team, before the product was even released?
(note the final sentence - well-tuned optimizing solution by the time the
system is released), more, that same article mixes C++/ISO and C++/CLI
stuff, like you did when you talked about PGO which is a native code thingy
( and btw. not very valuable either).
Other sources at MSFT, (contradicting the story in MSDN Magazine), have
clearly stated that the front end of C++/CLI which simply emits IL isn't a
target for agressive optimization which may hurt the correct functioning of
the JIT compiler. And the front end doesn't do any inlining at all, why?
well he can't, if you know what inlining is all about you will understand
why it's not possible at that level in a managed world, you can't inline IL,
point. Note that the article doesn't mention any figures reflecting the
advantages because of the optimizations included in the product, you know
why?

Willy.

Mar 9 '06 #68

"Shawn B." <le****@html.co m> wrote in message
news:Oc******** ******@TK2MSFTN GP10.phx.gbl...
| >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.
Not true, read the article, his findings reflect several builds including
the latest CTP Feb 2006 build 5308.
What Richard is trying to say is that NetFX is just a managed API in top of
unmanaged code, nothing more. He did expect Vista to contain more managed
code at the core, which is not the case, actually Vista does not contain any
managed applications, you can even run Vista without the framework
installed. All there is are some administrative applications (the event
viewer, and the performance monitor) that are build using WinFX WPF. But
that's only a facade, the underlying code is still managed (and n case of
perfmon, it's still the sme COM server code as on XP). All other stuff is
unmanaged, not using the framework at all and that's what Richard is ranting
about.

Willy.
Mar 10 '06 #69
Realy? Are you basing your findings on a piece written by a technical
editor, not a member of the C++ team, before the product was even
released?
(note the final sentence - well-tuned optimizing solution by the time the
system is released), more, that same article mixes C++/ISO and C++/CLI
stuff, like you did when you talked about PGO which is a native code
thingy
( and btw. not very valuable either). Other sources at MSFT, (contradicting the story in MSDN Magazine), have
clearly stated that the front end of C++/CLI which simply emits IL isn't a
target for agressive optimization which may hurt the correct functioning
of
the JIT compiler. And the front end doesn't do any inlining at all, why?
well he can't, if you know what inlining is all about you will understand
why it's not possible at that level in a managed world, you can't inline
IL,
point. Note that the article doesn't mention any figures reflecting the
advantages because of the optimizations included in the product, you know
why?


Every body is quoting a source. Everybody is contradicting everybody.
Personally, I don't care what people say. I received a major performance
boost by moving to C++/CLI in a particular piece of software. I didn't say
anyway that would hold true everywhere, just in this case it does. Despite
your findings, I've received the improvements in performance. That's what I
know.

And yes, you can inline IL. Even the Delphi.NET compiler does. There's
always a restriction but I don't care to argue.

The point is your tests prove your right. My real world applications proves
its possible that the C++/CLI compiler can produce a better app.
Done,
Shawn
Mar 10 '06 #70

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
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...
1
10575
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
10241
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
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
5642
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
0
5812
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?

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.