Disappointment in VC++ .Net in VS2008

[Edward Diener]

Why bother having Stan Lippman and Herb Sutter created a C++/CLI
language for .Net development when Microsoft, and the VC++ development
team, are so clearly intent on limiting .Net development with C++/CLI to
the smallest subset of .Net development technologies in Visual Studio,
while all of the new technologies are given to C# instead ? The bubble
has burst with VS 2008 and we are instead finally told quite frankly, by
a lead VC++ team developer, that VC++ is not going to be a first-class
..Net development language. In that case why bother with C++/CLI, since
it serves little to no purpose for C++ programmers anymore. Here is the
lineup:

1) ASP .NET, not for C++
2) Web services in .Net, not for C++ and even web services client
development is removed in VS 2008.
3) WPF, not for C++ and even creating controls for WPF is absent for
C++/CLI.
4) WCF, not for C++.
5) WWF, not for C++
6) LINQ, not for C++.

Finally all advanced web application development is remove from C++ with
the abandonment of the ATL Server.

VS 2008 is an abortion for C++ .Net developers in every way. The message
is now clear from Microsoft and the pretense is finally dropped "If you
want to do .Net development in C++, just forget about it and start
programming in C#". It should have been clear from the beginning, with
the miraculously appearing loader lock bug, but now is transparent.

Instead the big news in VC++ for VS 2008 is Vista updates for MFC of all
technologies. Gee, I am sure glad I learned a RAD technology like .Net
so I could go back to doing MFC development.

C++/CLI is such a good language, with so much careful and intelligent
decisions made so that it is superior to C# in almost every way, that it
is sad to finally realize that Microsoft never had any plans for C++
developers to effectively compete with C# developers in the .Net world.
It was just a sop so that they could attract C++ developers and turn
them toward C#.

Stan Lippman, Herb Sutter, Brandon Bray, and others, you should all be
ashamed of yourselves in leading VC++ straight to a dead end of
programming for .Net.

[David Ching]

"Norman Diamond" <nd******@community.nospamwrote in message
news:ea**************@TK2MSFTNGP05.phx.gbl...

I see no mention of version and compiler independence in the message that
you cited. If there were then it would surely be wrong.

There is no requirement for two compilers to agree on the length of a
long. There is no requirement for two compilers to agree on the
representation of negative numbers (one could use one's complement and one
could use two's complement) though of course for performance reasons most
sensible compilers for a single platform will agree on that. Two versions
of a single compiler might disagree on whether wchar_t is a separate type
or just a typedef for one of the integral types.

In P/Invoke, the caller's coder has to specify types that will map onto
the same number of bits and endianness and everything that the callee is
going to expect. But I didn't think this would depend on whether COM is
being used or not.

By using abstract interface classes, memory management issues are avoided
(as no data is specified). Because the only memory is the class's v-table
which is a 4 byte pointer in C compilers (all the ones that matter, anyway).
Of course, there are data types in params to the interface methods which
need to be compatible, but with Windows compilers, these are pretty standard
anyway. I haven't had a problem with this scheme with different versions of
VC++, but I'm not sure about compatibility with something like GNU. I
imagine Borland compilers would be OK too.

-- David

[John Carson]

"Edward Diener" <ed*******************@tropicsoft.comwrote in message
news:%2***************@TK2MSFTNGP03.phx.gbl...

>
It is hard for me to believe that improving MFC instead of improving .Net
programming should have been the focus of the VC++ team in the year 2008.
I am sure it is helpful to those C++ programmers who are still working
with lagacy MFC applications, but I view .Net as a huge step above MFC in
overall programming technology. Since I am pretty unhappy with the focus
VC++ took toward the past, I sure hope people programming MFC are happy
with what they got. Of the mainstream VC++ technologies, .Net programming,
standard C++ programming, and MFC programming I view the latter as easily
the poorest of the lot.

It is a fact that, as of now, .Net programming is little used by Independent
Software Vendors (ISVs), which overwhelmingly use native code. "Legacy"
applications include almost all of the major desktop applications and
Windows itself. Native will continue to dominate these spaces for some years
to come. Not all of these applications use MFC, but a lot do.

john carson

[Tamas Demjen]

David Ching wrote:

By using abstract interface classes, memory management issues are avoided
(as no data is specified). Because the only memory is the class's v-table
which is a 4 byte pointer in C compilers (all the ones that matter, anyway).
Of course, there are data types in params to the interface methods which
need to be compatible, but with Windows compilers, these are pretty standard
anyway. I haven't had a problem with this scheme with different versions of
VC++, but I'm not sure about compatibility with something like GNU. I
imagine Borland compilers would be OK too.

As long as a C++ compiler supports COM, it is guaranteed that abstract
virtual methods will work. On non-Microsoft platforms, however, there
are no guarantees regarding v-table compatibility.

With Borland compilers the most important compatibility issue is with
enum (it defaults to 8-bit in C++Builder, while it is int-sized in VC++).

Tom

[Ben Voigt [C++ MVP]]

"Tamas Demjen" <td*****@yahoo.comwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...

David Ching wrote:

>By using abstract interface classes, memory management issues are avoided
(as no data is specified). Because the only memory is the class's
v-table which is a 4 byte pointer in C compilers (all the ones that
matter, anyway). Of course, there are data types in params to the
interface methods which need to be compatible, but with Windows
compilers, these are pretty standard anyway. I haven't had a problem
with this scheme with different versions of VC++, but I'm not sure about
compatibility with something like GNU. I imagine Borland compilers would
be OK too.

As long as a C++ compiler supports COM, it is guaranteed that abstract
virtual methods will work. On non-Microsoft platforms, however, there are
no guarantees regarding v-table compatibility.

On many (most?) non-Microsoft platforms, there is an ABI specification
(application binary interface) providing much better guarantees regarding
compatibility.

>
With Borland compilers the most important compatibility issue is with enum
(it defaults to 8-bit in C++Builder, while it is int-sized in VC++).

Tom