What is Place of Managed C++ in .NET?

[Ioannis Vranos]

Even 50 doesn't sound extraordinarily high. I've always heard that
the transition was a limiting runtime factor, but that sounds like the
equivalent of calling a tiny subroutine.

Strange thing though, I've worked with code that didn't transition
smoothly when translated to VC++ with a managed wrapper/bridge.
I had assumed that it was the transition cycles. I guess I should
look elsewhere.

I do not know if this helps, but I recall that the additional run-time cost of DirectX 9
which is managed and wraps the previous version which is unmanaged, is 2%.


However wrapping must always be careful if we want to preserve performance. We must not
wrap things inside a loop, but rather the whole thing.

 

[Olaf Baeyens]

Even 50 doesn't sound extraordinarily high. I've always heard that

50 cycles inside a tight loop can get nasty fast. Also, this is just the
transition and does not include marshalling.

But in this case, you create a mixed managed/unmanaged C++ assembly that
does this thing in unmanaged C++ and then comes back to managed C++. This
way only one transition.

Creating assemblies is far easier done than creating normal dll's in .NET.

 

[Guest]

2) Is Microsoft intending to support C# and V.B. .NET more than Managed
C++?

Apparently that's already happened, even before VS 2005 is released. Over
on the "Channel 9" section of MSDN there is a sequence of videos proclaiming
the Class Designer as a truly wonderful tool you will use to build your
codes. This tool will be available for C#, VB, and J#, but the C++ version
was dropped from "whidbey" sometime in early March because it couldn't be
finished in the remaining time, with the needed quality. It is promised for
"a future release" of Visual Studio. Note too that along with Visual Studio
2005, MS will be selling the companion Visual Studio Tools for Office. It's
what you will use for programming with Word, Excel, etc. The supported
languages are C# and VB.NET.

At least that's my understanding of the current state of affairs. I welcome
any corrections, clarifications, or insight from MS VIPs or other insiders.

Wil

 

[Ioannis Vranos]

Apparently that's already happened, even before VS 2005 is released. Over
on the "Channel 9" section of MSDN there is a sequence of videos proclaiming
the Class Designer as a truly wonderful tool you will use to build your
codes. This tool will be available for C#, VB, and J#, but the C++ version
was dropped from "whidbey" sometime in early March because it couldn't be
finished in the remaining time, with the needed quality. It is promised for
"a future release" of Visual Studio. Note too that along with Visual Studio
2005, MS will be selling the companion Visual Studio Tools for Office. It's
what you will use for programming with Word, Excel, etc. The supported
languages are C# and VB.NET.

At least that's my understanding of the current state of affairs. I welcome
any corrections, clarifications, or insight from MS VIPs or other insiders.

Well I think there may be some tendency to leave C++ one step behind in each release of
VS. First it was the lack of designer support in VS 2002 -added in VS 2003-, then the
smart devices development support in VS 2003 -added in VS 2005 as far as I know -.

Now if you are correct the class designer, however for this there may be complexity
reasons, remember C++ is both worlds, managed and unmanaged and perhaps they could do not
make the class designer support both of them, in time.

However not provided C++ support for Visual Tools for Office, or support for web
programming, I think is clearly for leaving C++ a bit behind. As far as I can get, they
may feel better having you using VB and VC#, the same way that Borland for example may be
feeling better if you use Delphi (vendor lock-in).

However I think this is a mistake for MS, for two reasons. First there is *.NET* C#
support (more than .NET support for C++) from companies other than Microsoft. An example
is C# IDE by Borland. Another example is C# (and I think also VB) compilers by Mono and
run-time support of them (that is even C#/VB programs compiled with Visual Studio under
Windows, can run under Mono in Linux).

So I do not think there is any vendor lock-in for VC# and VB if this is the intention, and
C# especially, since C# is standardised (ECMA C#/CLI standard).

 

[Ioannis Vranos]

Well I think there may be some tendency to leave C++ one step behind in
each release of VS. First it was the lack of designer support in VS 2002
-added in VS 2003-, then the smart devices development support in VS
2003 -added in VS 2005 as far as I know -.

Now if you are correct the class designer, however for this there may be
complexity reasons, remember C++ is both worlds, managed and unmanaged
and perhaps they could do not make the class designer support both of
them, in time.

However not provided C++ support for Visual Tools for Office, or support
for web programming, I think is clearly for leaving C++ a bit behind. As
far as I can get, they may feel better having you using VB and VC#, the
same way that Borland for example may be feeling better if you use
Delphi (vendor lock-in).

However I think this is a mistake for MS, for two reasons. First there
is *.NET* C# support (more than .NET support for C++) from companies
other than Microsoft. An example is C# IDE by Borland. Another example
is C# (and I think also VB) compilers by Mono and run-time support of
them (that is even C#/VB programs compiled with Visual Studio under
Windows, can run under Mono in Linux).

So I do not think there is any vendor lock-in for VC# and VB if this is
the intention, and C# especially, since C# is standardised (ECMA C#/CLI
standard).

Second (and additionally), C++ is probably the dominant general purpose programming
language, and leaving behind this audience can only result them leaving you in the first
opportunity.

So in summary, leaving behind many *millions* of C++ programmers while at the same time
there is no real vendor lock in for C# and VB programmers, can only result in becoming
second or more behind, in the first opportunity.


Please tell me if I am missing something.

 

[William DePalo [MVP VC++]]

Well I think there may be some tendency to leave C++ one step behind in
each release of VS.

I guess that depends of your definition of "tendency". If you mean that
there is a clearly articulated strategy deliberately to limit the feature
set provided for the version of C++ that ships in VS.Net 2003 or 2005, then
this is quite simply not the case.

The C++ team members have posted here many times that their _goal_ is to get
C++ to the lofty place in the .Net food-chain that it occupies on the
unmanaged side.

Now, I can't tell you why some features do or don't make the cut for
inclusion into future products - obviously its an internal decsion - but I
can speculate.

My guess is that it is just harder to do because the language is so much
more complex by comparison to the others. And no organization, not even MS,
has unlimited resources. So, with deadlines looming, when push comes to
shove managers tend to look for the "biggest bang for the buck" directing
resources at those parts of a product that are most critcial to most of
their customers and putting off what they think will have the the smallest
payoff. That's just my opinion.

On the other hand, if by tendency, you aren't speaking of a strategy, but
rather just the nature of the more complex relationship between the language
and the platforms - Win32 and .Net - you may be correct. Time will tell.

Regards,
Will