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

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

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

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

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,tem plates,
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]

Shawn B. <le****@html.co m> wrote:

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]

Don Kim <in**@nospam.do nkim.info> wrote:

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.
--
- Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.

[Igor Tandetnik]

Tim Roberts <ti**@probo.com > wrote:

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]

Igor Tandetnik wrote:

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.

Tim Roberts wrote: 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