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

[Don Kim]

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

[David Lowndes]

>Im currently migrating our application from C/C++/MFC to C++\CLI.

Why?

Dave

[Herby]

Good question

#1 They are paying me to do it :-)

#2 Its a calculator engine working with very sensitive data that is to
be made available on the web.
There is now a demand to run it in 'safe' mode. So its for
security reasons.

Although performance is also very important to us. This is hard to
gauge without actually having a .NET version to do some benchmarks.
But im not seeing anything unduly slow at the moment.

Another reason is using the MONO platform for UNIX it should easily
port to UNIX. so opening up new potential customers there.
After all its is a VM, designed to compete with Java, ultimately they
must be planning for it to run on other platforms ?

[David Lowndes]

>#1 They are paying me to do it :-)

Always a very good reason :)

#2 Its a calculator engine working with very sensitive data that is to
be made available on the web.
There is now a demand to run it in 'safe' mode. So its for
security reasons.
OK, so you probably do have a reasonable technical argument for going
this way.
Another reason is using the MONO platform for UNIX it should easily
port to UNIX.
...
After all its is a VM, designed to compete with Java, ultimately they
must be planning for it to run on other platforms ?

Hmm, maybe. This is MS you're talking about. Have you tried this?

Dave

[Alex Blekhman]

Don Kim wrote:

Alex Blekhman wrote:

I hope we will see something in near future. I can see
that job market requires C#/.NET much more frequently
than C++. All these coders are doing something, isn't it?

I don't know why discussions of programming languages and
frameworks always digress into which is better or more
popular. *SIGH* Visual Basic classic had far more
programmers than Visual C++ ones, yet it does not mean it
was better (on the contrary, VB encouraged bad
programming habits, and was terrible at scaling above
small applications).

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.

Take as example textile industry. Hundreds years ago textile
was one of leading product of western world. Then industry
advanced and textile production became much cheaper. At the
same time it required more people, however their tasks were
much less advanced and required less training. At some day
it moved to Asia and Latin America; otherwise it wasn't
worthwhile. However, textile machines are still developed
and produced mostly in western countries.

The same process happens in software industry now. All
spadework goes to India, China and other countries where
coders are cheaper. However, as you already noticed, in
western countries, criteria for developers become more
demanding. This is natural process for any industry.
Software is not exception. Carefully handcrafted C++ code
can be as piece of art as finest French lace. However, there
are no skilled developers enough to make hand crafted C++
code for mass production. We can delude ourselves that C++
coders are "elite" while VB/.NET are "grunts" and all
"genuine quality" software should be developed by elite. The
industry needs more software and faster. It's not
economically viable to develop all of it with expensive
means.

[Nemanja Trifunovic]

> I mean applications like word processors, image editors,

CD/DVD burning software, etc.
Sorry, but I dissagree ;) There were good reasons these applications
were never written in VB or Java, and the same reasons hold today for
..NET
However, I reckon your application is some CAD and/or
scientific software. Regular e-mail client or accounting
application does not require such engineering effort.

Machine translation has nothing to do with CAD, it simply means
"automatic translation" or "computer translation" - try to google for
it if you are interested. As for e-mail clients, sure .NET would be
fine, except that there are so many existing e-mail clients already.
For accounting, I have seen the trend to move from general purpose
programming languages to specialized environments like Axapta or SAP.

[Herby]

>>The same process happens in software industry now. All

spadework goes to India, China and other countries where
coders are cheaper.

So is this the fate for all coding in the western world,
it is to be farmed out much cheaper to third world countries?
What are we to do?

Why do some companies take this route and others not?

I was recently talking to someone on the 'Essential C++\CLI" course
recently run in London of which there was only 10 people.
Anyhow, his company employ some indian programmers to maintain the old
MFC code, as they cannot get them cheap enough here.
But the indian programmers do not want to work on MFC either, they want
also to exclusively use the latest and greatest... The staff there keep
leaving and wage inflation is approx 15% pa.

[Nemanja Trifunovic]

> I mean applications like word processors, image editors,

CD/DVD burning software, etc..

Well, we will agree to dissagree on this :) I just don't see .NET
*ever* gaining any significant role in these areas.

[Herby]

>After all its is a VM, designed to compete with Java, ultimately they

must be planning for it to run on other platforms ?

Hmm, maybe. This is MS you're talking about. Have you tried this?

No not yet. Sounds good in theory though.

So is the VM part of .NET only virtual on top of Windows?

[Tom Serface]

Hi David,

I moved away from using VC6 for a couple of reasons probably #1 is my
"feeling" was that MSFT would stop supporting it. It still is what it is,
of course, so that doesn't change, but I'd like my resume to be more up to
data :o)

I've found that once I got used to the new interface in VS 7.1 and 8.0 I
actually like it better. I still miss ClassWizard, but I've learned to do
more things manually.

I don't really need great language conformance, I just need to create
Windows programs quickly that work. However, I am happy that there are
rocket scientists at MSFT making sure we are growing in that direction for
the inevevitable time when I will need something new.

The price seems to be creeping up as well, but since I live in this every
day it's easy enough, for me, to justify the cost. It's nice seeing the one
year moritorium on paying for the Express version.

Tom

"David Lowndes" <Da****@example .invalid> wrote in message
news:dv******** *************** *********@4ax.c om...

Im currently migrating our application from C/C++/MFC to C++\CLI.

Why?

Dave

[Carl Daniel [VC++ MVP]]

Herby wrote:

After all its is a VM, designed to compete with Java, ultimately they
must be planning for it to run on other platforms ?

Hmm, maybe. This is MS you're talking about. Have you tried this?

No not yet. Sounds good in theory though.

So is the VM part of .NET only virtual on top of Windows?

In theory, anyone can implement the CLI on whatever platform they choose
(witness Mono and dotGNU). In practice, there's quite a bit of the .NET
framework, including all C++/CLI support, that goes beyond what's in the
ECMA specs.

I'm not saying you won't ever see a CLI implementation on another platform
that supports C++/CLI - I believe you will eventually. But I strongly
suspect that it won't be this year. Or next.

-cd