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

[Andre Kaufmann]

Willy Denoyette [MVP] wrote:

"Andre Kaufmann" <an************ ****@t-online.de> wrote in message
news:OI******** ******@TK2MSFTN GP09.phx.gbl...
| Willy Denoyette [MVP] wrote:
|
| >
| > #using <sub.dll>
|
| What is this line for ?

used to refer to the assembly containing the metadata of the class C, but I
guess you know that.
An assembly in an external DLL ? Yes I know that. I only asked to be
sure that it was no typo.

Do you really expect other IL code to be inlined
| by the C++/CLI compiler ? This compilation/inlining is part of the
| .NET runtime, why should this be optimized by the C++/CLI compiler ?
| Nobody wrote that global optimization should work over other languages /
| external DLL's too.
|

No, I know that they can't inline (existing) IL, and that's exactly my point
and what I tried to prove, but OK, I have two separate assemblies (a DLL and
an EXE) which is somewhat misleading.
Yes it's misleading.
Would one expect the C++ compiler to optimize code in an external DLL ? No.
With IL code theoretically it could be done - but since the DLL is
loaded at runtime the compiler would have to optimize the code at
runtime ?! IIRC the C++/CLI compiler is not part of the runtime and
therefore cannot do that.

The C++/CLI "only" optimizes the code of a single solution - only
"source" code - no binary IL code.

No one expected or said that it would also optimize code of other
compilers residing in a DLL.

Ok - let's simply forget about external "DLLs" ;-) and let do that a
future .NET framework compiler.

Now, I guess your sourcecode files looks like this (please correct me when
I'm wrong):
Not quite. I've not used only a header file.

That would be "normal" inlining. I've separated the code into CPP /
Header file.
My code looks like the following:

Header:

public ref class C
{
public:
int Square(int x);
};
CPP:

#include "sub.h"
int C::Square(int x)
{
return x*x;
}
#include "sub.h"
int main()
{
C^ c = gcnew C;

int r = c->Square(42);
System::Console ::WriteLine(r);
}

Main is O.K.
It's true the call will be inlined, but this is one compiland (a sinle
source file)
Nope - 2 source files.
and is not what the article suggest [1]. The header file is
included in the one and only source file and then compiled, right?
No. As already said above it's separated in header and CPP file and only
a compiler with "link time" code generation is able to do that optimization.
< [1] article snip...
The compiler can now perform analysis and optimization across multiple
source files. Without WPO, for example, the compiler can only inline
functions within a single compiland. With WPO, the compiler can inline
functions from any source file in the program.>

now if you make it two compilands (two source files).
Like in my sample.
// file sub.h, common header
public ref class C
{
public:
int Square(int x);
};

// file sub.h
#include "sub.h"
int C::Square(int x)
{
return x*x;
}

// file main.cpp
#include "sub.h"
int main()
{
C^ c = gcnew C;
int r = c->Square(42);
System::Console ::WriteLine(r);
}

And compile its using:

cl /c /clr:safe /O2 sub.cpp
cl /clr:safe /O2 main.cpp sub.obj
You see no inlining any more.
I wouldn't expect them to be inlined with /O2.

You don't use global optimization. Without that option the compiler
cannot do "global optimization" which is required for /GL and /LTCG
If you have other options, that would inline accross source files, I would
be happy to hear how.
/GL and /LTCG
Willy.

Andre

[Willy Denoyette [MVP]]

"Andre Kaufmann" <an************ ****@t-online.de> wrote in message
news:OA******** ******@TK2MSFTN GP11.phx.gbl...
| Willy Denoyette [MVP] wrote:
| > "Andre Kaufmann" <an************ ****@t-online.de> wrote in message
| > news:OI******** ******@TK2MSFTN GP09.phx.gbl...
| > | Willy Denoyette [MVP] wrote:
| > |
| > | >
| > | > #using <sub.dll>
| > |
| > | What is this line for ?
| >
| > used to refer to the assembly containing the metadata of the class C,
but I
| > guess you know that.
|
| > If you have other options, that would inline accross source files, I
would
| > be happy to hear how.
|
| /GL and /LTCG
|
| > Willy.
|
| Andre
Ok, here is what I got when compiling with:

cl /O2 /clr:safe /GL main.cpp sub1.cpp
or:
cl /O2 /clr:safe main.cpp sub1.cpp /link /LTCG

IL_0000: ldc.i4 0x6e4
IL_0005: call void [mscorlib]System.Console: :WriteLine(int3 2)
IL_000a: ldc.i4.0
IL_000b: ret

You need both /GL and /O2 however, I did try both option separatly.

I was wrong, I stand corrected.

Willy.