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

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

 

[Ajay Kalra]

Don,

I am in agreement with you regarding CLI/C#. I dont think CLI is
gaining any momentum. Even MC++ did not gain any momentum. It may have
been different had CLI been released when .Net as first released. But I
really doubt it.

But in my view, the main factor is that applications developed using
MFC/ATL/Win32 typically do not have any need to go managed. There is no
compelling reason to do so. It really does not buy you anything other
than possible headaches(more QA) and possibly performance issues. For a
existing commercial unmanaged application written in C++, its a major
step. In my view, C++ in managed land is kind of not natural. It was
hard to see Herb Sutter asking for input to modify C++ to its present
managed form(CLI) (that too in Redmond).

As far as C# vs CLI is concerned, C# wins mainly because of its
ease(compared to C++) and was marketed very well compared to CLI.

 

[Shawn B.]

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

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.

C++/CLI is much better... but I would have preferred if they left the syntax
alone. Instead of all this "ref" stuff and "^" pointers, they should have
just said

managed class MyClass
{
....
public:
void DoSomething(int *myInt) // * pass by reference
{
...
}

unmanaged int DoSomethingElse()'
{
}
}


and perhaps a few .NET specific things that aren't expressible in standard
C++... but for the most part, I think the C++/CLI syntax is "quircky" though
better than MC++.

I use C++/CLI (sometimes) instead of C# because (some of) the types of
project I create see significant performance increases when using the
C++/CLI compiler instead of C# because the C++/CLI compiler will optimize
code during compile time instead of leaving everything to the JIT'er as C#
does. This results in drastically better performance .NET applications for
the things I use C++/CLI for. Usually I use C#, though.

That said, I'm noticing C++/CLI making slow uptake also, but all things .NET
2.0 seem to be slow. Don't know why. Perhaps its because the "awe" factor
of the new 2.0 features wore off two years ago when they first starting
talking about it. Now its out and its no big deal. I predict the same for
..NET 3.0.


Thanks,
Shawn

 

[Stephen Howe]

But in my view, the main factor is that applications developed using

MFC/ATL/Win32 typically do not have any need to go managed.

Exactly. GC has been around for many decades. It is not new. MS gives the
impression they have created brand new technology - they have not.
It solves one set of problems and introduces others
There are some applications that might benefit, not all applications. Many
will be slower - by a lot.
To me, the whole of .NET is political. It is not an advance.
It is designed to take on and kill Java.

There is no compelling reason to do so.
Exactly

It really does not buy you anything other than possible headaches(more QA)

and possibly performance >issues.

Exactly. Waste of time. I can see MS evangelists dancing, writing
whitepapers, articles, books all to herd managers and programmers in
companies to write new apps, rewrite old apps as .NET applications.
And for what? They won't be any faster. Some will be a lot slower.
There is nothing particularly wrong with Win32.
Given 10 years, MS will abandon it.
It is no more than the latest programmer fashion.
Any manager reading this - avoid it. Only consider if it provides some easy
functionality you need that is not easy to code using Win32 APIs.

We have MFC7 apps and Win32 DLLs in our company. None of them need writing
as a .NET app.
No benefit whatsover.

For a
existing commercial unmanaged application written in C++, its a major
step. In my view, C++ in managed land is kind of not natural. It was
hard to see Herb Sutter asking for input to modify C++ to its present
managed form(CLI) (that too in Redmond).

He has done a good job.
The first version of managed C++ was appalingly clunky.
The current version is much better.
Even so, I am not enam

As far as C# vs CLI is concerned, C# wins mainly because of its
ease(compared to C++) and was marketed very well compared to CLI.

Not sure about that.
Right now there are many dialects of the same syntactic langauge - C++,
C++/CLI, C#, Java, D
which take various positions on single/multiple inheritance,templates,
garbage collection.
I personally think that in the long run C# will lose. It is only .NET and
Windows.
C++ is available for multiple platform, it does not require graphics and
there are many bright people continually inputing into its development in
terms of a ISO standard.
Java will still be around but it has lost its way somewhat.
D is one to watch.

Stephen Howe

 

[Igor Tandetnik]

C++/CLI is much better... but I would have preferred if they left the
syntax alone. Instead of all this "ref" stuff and "^" pointers, they
should have just said

managed class MyClass
{
...
public:
void DoSomething(int *myInt) // * pass by reference

There are good reasons to keep * and ^ separate, and for other C++/CLI
design decisions. See

http://www.gotw.ca/publications/C++CLIRationale.pdf

From the horse's mouth, so to speak.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

 

[Shawn B.]

There are good reasons to keep * and ^ separate, and for other C++/CLI

design decisions. See

http://www.gotw.ca/publications/C++CLIRationale.pdf

Yeah, I've heard many of them and still dissagree somewhat. I won't argue
why because its unimportant. What is important is that C++/CLI is much
better than unmanaged C++ and the MS C++/CLI compiler can (in some cases)
produce better code than C# equivelant code, only because of the
optimizations the C++ compiler does, though, that C# does not do. But with
future revisions of .NET and dev tools/languages, it'll get better.


Thanks,
Shawn

 

[Nemanja Trifunovic]

I can't help but agree. The unfortunate experiment with "Managed
Extensions for C++" is one more reason for the failure of C++/CLI.
Those of us who have invested time in learning MC++ and developed
applications and libraries with it will think twice before moving to
C++/CLI. Technically speaking, the new language is great - it simply
lacks the momentum.

 

[Tim Roberts]

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.
...
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 strongly question your assertion that C++/CLI allows someone to "preserve
their existing native C++ code". C++/CLI differs from C++ almost as much
as C# does.

Moving from C++ to C++/CLI requires you to mix new keywords and new
operators into a vaguely familiar language. The resulting mishmash of
familiar and unfamiliar is likely to cause errors just by itself. It makes
more sense to just invest the effort in learning C#, which has a large
collection of well-tested samples to draw from.

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.

This is in interesting paragraph, from someone who three paragraphs ago
referred to buying "into the .NET hype". It sounds like you already
believe that all Windows programming from now on will be .NET.

 

[Igor Tandetnik]

I strongly question your assertion that C++/CLI allows someone to
"preserve their existing native C++ code". C++/CLI differs from C++
almost as much as C# does.

The theory is that one can build a project that contains regular C++
sources freely mixed with C++/CLI sources, they can call into each
other, and it all just works with no interop tricks required. Thus one
can take legacy code and simply start using it in a managed program.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

 

[Don Kim]

The theory is that one can build a project that contains regular C++
sources freely mixed with C++/CLI sources, they can call into each
other, and it all just works with no interop tricks required. Thus one
can take legacy code and simply start using it in a managed program.

Thank you, this is what I meant. Unfortunately, some of the companies I
interviewed with and others I have inquired from, seem to be unaware
of this feature of C++/CLI (let alone even know of its existence!) and
are seeking to REWRITE all their C++/Win32/MFC/ATL code to C#/.Net!
First of all, its nuts to rewrite working code just to keep up with some
trendy new framework, even as good as .Net is for certain class of
applications. But if your going to do so, might as well use the C++/CLI
extension that was expressedly created to allow such a migration path,
so you can save the time and wasted effort of re-writting code.

But therein lies my rant, in that it seems this feature and new language
extension has not been marketed well, or the first iteration of MC++ was
so bad, NO one wants to risk investing effort in it. I know I occupy
this position.

Its a pity, because it seem so much time and effort was put into
creating this extension, even going so far as submitting it to be an ISO
standard.

This is in interesting paragraph, from someone who three paragraphs
ago referred to buying "into the .NET hype". It sounds like you
already believe that all Windows programming from now on will be
.NET.

No, I do not believe all windows programming will or should be .net.
Its just an observation I have of many IT companies that I have been
seeking work with, that THEY are under the impression that ALL windows
programming will/should be .net. Thus, my original rant that they are
1) crazy to re-write existing and working C++ code to C#, just because
of this fallocious belief, 2) unaware that there is a new and cleaner
language extension (if you notice, I refer to this as a language
extension, because for the most part I don't consider C++/CLI to be ISO
C++, but just an extension of it) to help with this migration if they
are so inclined, and 3) the reason for this was because of the
lackluster job of the first managed extension and continuous lackluster
job of marketing this feature.

Regards,

-Don Kim

 

[William DePalo [MVP VC++]]

Igor Tandetnik wrote:
But therein lies my rant, in that it seems this feature and new language
extension has not been marketed well, or the first iteration of MC++ was
so bad, NO one wants to risk investing effort in it. I know I occupy this
position.

It's important to quantify "bad".

MC++ was "bad" in my view because the code was so ugly with all its double
underscored keywords. (But then everyone has his own subjective esthetic
criteria for attractiveness.) With the exception of the "loader lock" issue
which was more of an issue in how the language and runtime interact than
anything else, the language was not "bad" in the sense that it was
unworkable.

I used it to good advantage so that a server application of mine can support
plug-ins written in managed languages. It rocks at that.

And I think that's where MC++ and C++/CLI shine. They make it easy to
interoperate between native and managed components.

Regards,
Will

 

[John Carson]

Thank you, this is what I meant. Unfortunately, some of the
companies I interviewed with and others I have inquired from, seem
to be unaware of this feature of C++/CLI (let alone even know of its
existence!) and
are seeking to REWRITE all their C++/Win32/MFC/ATL code to C#/.Net!
First of all, its nuts to rewrite working code just to keep up with
some trendy new framework, even as good as .Net is for certain class
of applications. But if your going to do so, might as well use the
C++/CLI extension that was expressedly created to allow such a
migration path, so you can save the time and wasted effort of
re-writting code.
But therein lies my rant, in that it seems this feature and new
language extension has not been marketed well, or the first iteration
of MC++ was so bad, NO one wants to risk investing effort in it. I
know I occupy this position.
Its a pity, because it seem so much time and effort was put into
creating this extension, even going so far as submitting it to be an
ISO standard.

A lot of Microsoft initiatives don't work at the first attempt. Windows
itself never got real traction until version 3.0. If MS believes in
something and keeps working on it, it usually ends up a success. Present
indications are that there is a lot of support within MS for C++/CLI and it
has attracted some sympathy from the broader C++ community. Stroustrup's
most recent take on it is here:

http://public.research.att.com/~bs/bs_faq.html#CppCLI

That said, I think it is inevitable that in the future C# will be more
widely used for Windows programming than C++ or C++/CLI for the same reasons
that VB was so popular. C# is considered to be an easier language --- at
least for simple tasks --- in which you can get a lot of stuff done more
quickly. C++/CLI will tend to be popular for more demanding applications
written by programmers for whom language simplicity is not a priority.

 

[Alex Blekhman]

[...] Waste of time. I can see MS evangelists dancing,
writing whitepapers, articles, books all to herd managers
and programmers in companies to write new apps, rewrite
old apps as .NET applications.
And for what? They won't be any faster. Some will be a
lot slower.
There is nothing particularly wrong with Win32.
Given 10 years, MS will abandon it.
It is no more than the latest programmer fashion.
Any manager reading this - avoid it. Only consider if it
provides some easy functionality you need that is not
easy to code using Win32 APIs.

Why this fixation on speed? .NET was not invented to make
applications run faster. Who needs this speed anyway?
Overwhelming majority of desktop applications are fast
enough for any human user (unless scientists invented direct
connection between brain and computer). I don't need any
additional speed for my e-mail client or accounting
applicaton. However, I need additional interoperability,
modularity, ability to make extensions, ability to expose my
app to Web easily and other gazillion things that .NET
provides. To write all that in Win32 API is insane and
simply not realistic anymore. There are no Herb Sutters and
Stanley Lippmans enough out there to complete every
programming team with them.

..NET is not programming fashion. It is vital need of modern
software development. Applications are big and complex
nowadays. Time to market is shorter and more demanding. No
sane manager can afford himself the delusion that his
product can compete while using outdated technologies.
Almost any feature now is "some easy functionality you need
that is not easy to code using Win32 APIs". Can you imagine
today any decent desktop application without scriptability,
automation, possibility to make add-ons for it; without
highly customizable UI? Suppose, you have genius developers
and they managed to make it in Win32 API. Then what? How do
you think to convince your partners to make extensions for
your application? Where they should search for genuis
extension writers and support staff? Why they should invest
a lot of money to make additional training for existing
staff?

With .NET many of these questions are simply not exist.
That's why it is already (not in 10 years) .NET is primary
development platform for WIndows applications.

 

[Nemanja Trifunovic]

..NET is a preferred platform for *some* applications - roughly speaking
the same ones that were previously developed with tools such as Visual
Basic, Power Builder, Java and Delphi. There are many areas of software
development where .NET is not the best choice.

Anyway the point here is not whether or not to develop new applications
with .NET. If you have invested 10 years and millions of dollars into
building an application with, say, Win32 API - is there really a
business justification to rewrite it with .NET?

 

[Tamas Demjen]

C++/CLI is much better... but I would have preferred if they left the syntax
alone. Instead of all this "ref" stuff and "^" pointers,

C++/CLI was designed to support mix-mode programming, where a
significant potion of your code is native C++, which you wrap and
interface to .NET. That being said, it would be extremely inconvenient
to use a * for a managed handle. That contributed to the failure of the
old MC++. How would you know that int* is an unmanaged or a managed
pointer? Yes, if you develop in entirely managed mode with completely
totally 0 line of unmanaged code, the new C++/CLI syntax may look like a
severe deviation from ISO C++. But knowing the significant paradigmatic
differences between native and managed software design, you can't reuse
existing C++ code unmodified anyway.

they should have just said
managed class MyClass

Or better yet

class MyClass : public System::Object

Yes, they could have created a language allowing us to use a single
source base to produce both native and managed output, without having to
use quirky syntax. However, that wouldn't have been anything but a
skin-deep solution, which wouldn't have solved any real-world problems.
Existing ISO C++ code creates objects on the stack, which you can't do
very well in .NET (except with limitations, and only in C++/CLI, not in
the other .NET languages). Anything but the most trivial code uses STL
containers, std::string, maybe even boost::shared_ptr. Those concepts
don't work well in .NET, at least not in a portable way. How would you
compile existing source code using std::string to managed code? Would
you substitute std::string with System::String? Of course you can
compile std::string to managed code as a value class, but you won't be
able to expose that interface to the public.

In reality, if you want to reuse existing C++ classes, you don't do that
by recompiling them to managed types, but by wrapping them, which leads
to the problem of mixing unmanaged and managed data in the same code.
It's a huge benefit that you can immediately differenciate between those
types just by looking at the code. Class^ is managed. Class* is native.
I think it was a good enough reason to introduce the new syntax.

Tom

 

[Alex Blekhman]

.NET is a preferred platform for *some* applications -
roughly speaking the same ones that were previously
developed with tools such as Visual Basic, Power Builder,
Java and Delphi. There are many areas of software
development where .NET is not the best choice.

Of course, .NET is not an answer for all problems. There
will always be niches with specific needs. I'm talking about
mainstream development. Today mainstream steadily drifts
towards .NET/Java away from C/C++.

Anyway the point here is not whether or not to develop
new applications with .NET. If you have invested 10 years
and millions of dollars into building an application
with, say, Win32 API - is there really a business
justification to rewrite it with .NET?

It depends. At some point you will be forced to make some
modernizations, otherwise you will start to loose your
market share. To find the golden path between development
costs and competitiveness is the problem of every business.
Too many good application lost their markets because of
inability to adopt to changing environment.

The problem here that once complex feature you so cherished
(which costed you millions) can be easily implemented with
new technologies now. It gives significant competitive
advantage to your rivals. Now they need less developers to
implement the feature and those developers can be less
expensive than yours. Then competitor can concentrate on
more important things and make actually better product.

Currently, I can see that some big companies instead of
twisting old product's arms start to develop similar product
in parallel with new technologies.

 

[Nemanja Trifunovic]

I'm talking about

mainstream development. Today mainstream steadily drifts
towards .NET/Java away from C/C++.

What do you mean by "mainstream development"? If it is in-house
business applications, they were developed mostly by languages like VB,
Java or Delphi (or COBOL is you go farther in the past). If you mean
web browsers, office aplications, image processing, multimedia,
games... I don't see .NET playing significant role in these areas ever.

The problem here that once complex feature you so cherished
(which costed you millions) can be easily implemented with
new technologies now.

Sometimes yes, but in general no. For instance, we have a machine
translation engine that has been developed since 1991 or so. I can
assure you there is absolutelly nothing in .NET that would help us
easily reimplement it. We would simply lose another 15 years to get the
same thing - only it woud be slower (and speed does matter in this
case) and spend more memory.

 

[Don Kim]

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

Nevertheless, history seems to repeat itself, and this was the same kind
of thinking in the mid 90s when java hit the scene, and everyone
proclaimed c++ was obsolete. Well, foward 10 years and c++ seems as
strong as ever.

Consider though that C#/.Net seems to have been created because 1) it
was an answer to java and Sun's lawsuit; 2) VB was too easy and created
buggy, unscalable programs; and 3) C++ is hard and takes time to master,
and not everyone is inclined nor patient enough to use the language
properly. Thus, a mid level language was created that had the RAD
capabilities of VB, yet retained many of the system level capabilities
of C++. Great, from a business point of view, I can't blame MS for
doing this at all. Also, it raises the barrier to entry and promotes
better software engineering principles, since to use .Net effectively,
you have to really understand OO and compoent software design.

Again, and ad nauseum, 10 years from now .Net will be seen to not solve
everything (in fact, people already seem much smarter about this than
the java hype days, except for the younger programmers just out of
college weaned on java and thinking managed environments are superior to
everything else, and think all programs should be OO or worse,
shoehorned into design patterns because they took a class in OO/Design
Patterns and create these over elaborate OO hierachies, when a more
simple solution could have been created, yet they think they know it
all), and c++ will still run strong and solve what it is good at,
systems programming.

But again, and ad mauseum, ad nauseum... a good software developer will
carefully evaluate the problem at hand, and use the appropriate
programming language and framework, and much of this cannot be
determined solely on technical merits alone unfortunately, as the costs,
time to market, and skillset of the other developers will have to be
carefully evaluated and taken into consideration. That being said,
there are certain problems for which a language like c++ is best suited
for (sometimes the only solution), and it is incumbent on the developer
to know how to use it when necessary.

Besides, being this kind of developer will prevent you from having your
skillset become obsolete, and worse, become replaced by someone in
another country who can do the same work as you for a whole hell of a
lot cheaper. All this talk about how much easier it is to program in C#
and how fast you can create applications with it, is ironic, given that
this very same aspect of it, will make many millions of other programmer
in countries like India, China, and Eastern Europe adopt it and learn
it, and replace you.

This is not to say that C++ programmer will not get replaced either, but
the ones who know how to solve more complex problems, as well as have a
diverse skillset and knowledge base, have a much better chance of not
being replaced.

I've noticed the companies I interviewed with, are much more rigorous in
their hiring criteria and most positions are for senior level
developers, and I've noticed a surprising number of companies are asking
how you can handle many non-technical issues, such as being able and
willing to write technical specification documents, interact with
customers, and how well you can handle business concerns.

If all you can say is "C#/.Net is great and I know how to drag and drop
controls on a web/winform and wireup some bindings to an SQL database
and I have the MS certifications to prove it", you will either get the
most menial coding work and/or get replaced down the line by a coder in
Bangladore, or heck, someone in New Mexico because the company moved
their IT deptment there to save on rent and salary expenses.

Anyway, don't know how (or why it always does so) regress to a debate on
whether native or managed applications are better, but my original post
was not on whether the C++/CLI was good or bad on technical grounds (as
I actually think it is quite good), but more a slam on the lack of
marketing and promotion of it, in comparason to C#/VB.NET, especially
given all the work put into it. I do think, and if history is any
indicator of the tenaciousness of MS when the want companies to adobt
their technology (just look how good a job they did with .Net), that
they will with C++/CLI, its just that I'm getting impatient. C'mon lets
get moving!

Regards,

-Don Kim

 

[Alex Blekhman]

What do you mean by "mainstream development"? If it is
in-house business applications, they were developed
mostly by languages like VB, Java or Delphi (or COBOL is
you go farther in the past). If you mean web browsers,
office aplications, image processing, multimedia,
games... I don't see .NET playing significant role in
these areas ever.

I mean applications like word processors, image editors,
CD/DVD burning software, etc.. Currently there is a lot of
legacy C/C++ code out there. But slowly it changes. Most of
applications average consumer uses don't have significant
technological breakthrough inside them. Majority of parts of
DVD burner, for example, are boilerplate GUI, which is glued
together; there's no reason to invest in Win32 API to
implement it nowadays.

Sometimes yes, but in general no. For instance, we have a
machine translation engine that has been developed since
1991 or so. I can assure you there is absolutelly nothing
in .NET that would help us easily reimplement it. We
would simply lose another 15 years to get the same thing
- only it woud be slower (and speed does matter in this
case) and spend more memory.

This is the case when porting to .NET is not justifiable.
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.

 

[Herby]

Im currently migrating our application from C/C++/MFC to C++\CLI. We
are experienced C\C++ programmers and it would seem the natural path.
I am also quite impressed with the IJW technology. I can easily
convert my MFC serialization to .NET serialization within the same
mixed mode method and its completely intuitive.
IJW is a sound technology. It is easy to compile a single module to
managed mode and begin to introduce .NET features into your old
application, the rest stays unchanged and unmanaged. Its this fact
that needs to be appreciated by the hardcore C/C++ development teams.
Here we have evolution and not revolution.

Anyway our specific problem now is, we need to employ a junior
programmer to do some of the more mundane time-consuming tasks, but the
C++ developers out there are all senior. So the problem is you cannot
fill junior positions with old technologies. They all want to use C#.