Disappointment in VC++ .Net in VS2008

  • Thread starter Thread starter Edward Diener
  • Start date Start date
Larry Smith said:
You're using the term "complement" very loosely however. I could just as
well say that VB complements C++ on the GUI side. The real issue for me
however is the very presence of two languages. It makes the entire process
of developing software inherently more complicated and expensive.
Click to expand...

I respectfully disagree. It's quite useful to have tailored languages to
particular tasks, as long as the integration effort is low. Just because a
program needs to call some library that must be implemented with assembly
language (like Interlocked* functions), should the entire program be forced
into assembler? Of course not. regexes in C++ are ugly, much better to
use perl for that. Child process automation in C++ is ugly, much better to
use tcl/expect for that.

C++/CLI is a quantum leap forward in this respect because it exposes the
native power of raw C and assembler to a managed environment, and it does so
*easily*. Compare the effort needed to make a .NET component in C++/CLI vs
creating a Java JNI, TCL extension, Perl binary module, etc in C or C++.
I've heard Lua and Ruby are the other high level language that integrates
very well with C, and I doubt even they make it as trivial as C++/CLI.

For example:

void asmbreak( void )
{
__asm int 3;
}

public ref class Fragile
{
public:
static void BreakMe() { asmbreak(); }
};

What's that, under 30 tokens (not counting the assembly itself) to make any
assembler code available to a C# or VB.NET or JS.NET or F# or Eiffel.NET
program?
 
It's quite useful to have tailored languages to particular tasks, as long
as the integration effort is low
Click to expand...

Integration is a secondary concern. The complexity of supporting two large
and complicated languages like C# and C++ is your main concern. Now you need
expertise on your staff not only in two languages, but two platforms
(managed and unmanaged). This creates serious problems on various fronts.
One language, one platform. Life is now so much more simple. If the gaps
were closed between .NET and the WinAPI then this could be a reality. You
would then need to turn to another language/platform only when necessity
truly demands it. In practice that would almost be never (for most
organizations anyway).
 
Good point that we don't really know for sure. But say the reason were to
tie us to a proprietary language/OS. They could do that by creating a
Borland C++Builder-like environment which is native and still proprietary.
Click to expand...

There'd be less of a tie in because it would have to interface
seamlessly with standard C/C++ code - like C++/CLI does :)
So locking us into a proprietary environment alone does not explain why they
pushed managed.
Click to expand...

It won't be the whole story, there will be grains of truth in all
arguments we get to hear - and the ones we don't hear.

Merry Christmas
Dave
 
From our point of view, the company's neglect has contributed, but I still
think you are missing something huge: if the marketplace had been more
receptive, the company would not have neglected it.
Click to expand...

That assumes that MS listen to all their customers - they've recently
discovered (with the renewed interest in native VC++) that they
haven't been listening to all their customers... though I suspect the
situation is more that they haven't *heard* from all their customers!

The segment of their customers who use native C++ probably don't
attend the marketing shindigs (TechEd/MSDN events) that's the normal
capture for those gigs.

Merry Christmas
Dave
 
Come to think
of it, that would be a great Intellisense feature: draw a red squiggly
underneath a declaration of an IDiposable class that does not have a 'using'
statement.
Click to expand...

I think the easiest solution would be to pull the warning that the
static code analysis gives into the C# compiler so we see it for a
normal compile pass. That may give it a squiggle automatically?

Would anyone want to vote on that (if it's not already filed on
connect)?

Dave
 
Maybe I've just been too trusting however. In any case, you can quickly
discover if a class implements "IDisposable" by looking at its definition in
code (via the "GoToDefinition" command typically).
Click to expand...

All this misses the simple fact that some developers (most likely the
target audience for C#) don't know about the using statement (or the
issue it solves).

I've been working on a mixed C# C++/CLI project for the last year and
have had to educate my colleagues to its existence despite being the
last man in on the C# code. Consequently we have loads of code that
probably ought to have using statements - but doesn't.
The issue of
"IDisposable" is nevertheless a very tiny one in the grand scheme of things.
Click to expand...

I think it's actually quite a fundamental issue that the language has
such an unintuitive hole in it.
... C++ should have been used in the first place.
Click to expand...

We agree on that :)

Merry Christmas
Dave
 
David said:
All this misses the simple fact that some developers (most likely the
target audience for C#) don't know about the using statement (or the
issue it solves).

I've been working on a mixed C# C++/CLI project for the last year and
have had to educate my colleagues to its existence despite being the
last man in on the C# code. Consequently we have loads of code that
probably ought to have using statements - but doesn't.


I think it's actually quite a fundamental issue that the language has
such an unintuitive hole in it.


We agree on that :)
Click to expand...

Whether you use C++/CLI, with it's better destructor semantics or C#
with its IDisposable.Dispose(), .Net and other purely GC languages have
the fundamental flaw that the release of non-memory resources has to be
handled manually.

The "using" statement is a neat shortcut only when an object of an RAII
class is used locally and then destroyed, releasing its resource(s). If
that object needs to be passed around so that the last reference to the
object which is destroyed releases the resource, there is no solution in
.Net ( and other pure GC languages ) other than "don't do that because
if you do you will have to invent some means of keeping track of the
object's references yourself." As you may well know in native C++, which
is not a GC language, boost::shared_ptr<T> will do exactly that for you,
as well as releasing the memory of the object.

However all this has little to do with my OP, althoug I do undertsand
how the discussion started.

Nonetheless I thank all people who have responded. Perhaps if C++
programmers had been more indignant in their interactions with Microsoft
and the VC++ team, the history of C++/CLI and its reduction to a second
class language would not have happened.

However I continue to believe that it did happen not largely for
technical reasons but because Microsoft's need to rope C++ programmers
in to using their own language, C#, was far more important to them and
their business than the honest competition between two similar but
different technologies.
 
I don't recall hearing any promises that C++/CLI was supposed to be on
equal footing with C# and VB.NET in the .NET world.
Click to expand...

I do. (Pedant's corner: I read it not heard it.)

I also remember when Visual Studio 2005 broke that promise in Windows Mobile
projects.
 
And C++/CLI is the only way to go if you need mixed-mode, p/invoke simply
cannot interop with a non-COM C++ library.
Click to expand...

That seems to be wrong. You and I couldn't figure out how to do it, but
someone did, and some of my C# code has been a client of it.
 
Norman Diamond said:
That seems to be wrong. You and I couldn't figure out how to do it, but
someone did, and some of my C# code has been a client of it.
Click to expand...

Ok, it might be possible, but it must be relying heavily on undefined
behavior and reverse engineering the C++ compiler. It's not a good idea,
and is prone to break at any time, such as following some Windows Update.

Even C++ cannot safely use a C++ library in a separate DLL without using a
framework such as COM.
Ben Voigt said:
Edward Diener said:
Ben Voigt [C++ MVP] wrote:
Tom Walker wrote:
message 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#.

What's wrong with you? If you know only one programming language you
are a dinosaur. Use C++ when appropriate. Use C# when appropriate.
Use
other languages when appropriate. Stop being anal. Get over it. Move
on. Happy Holidays.

I know C#, Java, and Python very well, thank you.

So it is absolutely normal to you that C++/CLI, despite being a
version
of C++ expressly created for .Net programming, should not have the
same

No, it is not!

It is designed expressly to bridge the gap between .NET and native
code,
whether internal implementation of the BCL, advanced use of Win32 APIs,
or existing C++ libraries.

It does that very well. Any future improvements are focused on doing
that better (bridging generics with STL containers, etc).

End of story.

How nicely to just "end the story" once technology is redefined to your
own ends. There was never the slightest talk of C++/CLI being designed
simply to bridge the gap between .NET and native code ( by which I have
to assume you mean the native Windows API ) and it is nonsense to
interpret it that way since .Net interop also does the exact same thing.
Click to expand...

I do not just mean the native Windows API, although that's a substantial
value. Also, .NET interop may be the underlying layer (unless compiling
with /clr and not /clr:pure) but only the C++/CLI compiler brings you
interop in a usable package. And C++/CLI is the only way to go if you
need mixed-mode, p/invoke simply cannot interop with a non-COM C++
library.
There was a great deal of talk and hype and promotion, especially by
Herb
Sutter, but also by Stan Lippman, of C++/CLI being a language for C++
programmers to access the .Net framework, with the unspoken assumption
that the VC++ team would make sure that C++ programmers would have the
same facilities to do so as any other .Net language else why should C++
programmers bother to learn and use it.

That lie has now been exposed in the latest VS 2008 release and by the
remarks of members of the VC++ team and now we find out that C++/CLI,
all
of a sudden, was never meant to be a first class language to access
.Net.
Click to expand...


As I understood it, it was hyped for library development, for extending
the MS-provided framework. It excels at that.
In the face of the sudden change of direction for C++/CLI it is
fruitless
to continue it for mainstream .Net programming. I will continue to use
VC++ for native Windows programming tasks, as I do at my job, but there
is no question that using C++/CLI for .Net programming is now largely a
wasted task.

I have already used previously a C++ extended language which was treated
as a second class programming language in another RAD environment and I
do not tend to do so again.
Click to expand...
Click to expand...
Click to expand...
 
David Ching said:
I had thought that if the C++ DLL exported abstract class interfaces, then
it was version and compiler independent. See
Click to expand...

It is if it is done consistently and memory ownership rules are also
followed. That's what I meant by a framework similar to COM.
 
Ben Voigt said:
It is if it is done consistently and memory ownership rules are also
followed. That's what I meant by a framework similar to COM.
Click to expand...

Sounds good, thanks.

-- David
 
David Ching said:
I had thought that if the C++ DLL exported abstract class interfaces, then
it was version and compiler independent. See
http://groups.google.com/group/microsoft.public.vc.mfc/msg/52593fb779fd1acb
for further thoughts. If something like this will not work, I'd be
interesting in discussing it.
Click to expand...

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.
 
Why bother having Stan Lippman and Herb Sutter created aC++/CLI
language for .Net development when Microsoft, and the VC++ development
team, are so clearly intent on limiting .Net development withC++/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 withC++/CLI, since
it serves little to no purpose forC++programmers anymore. Here is the
lineup:

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

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

VS 2008 is an abortion forC++.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 inC++, 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 forC++
developers to effectively compete with C# developers in the .Net world.
It was just a sop so that they could attractC++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.
Click to expand...

Try C++ Builder 2007.
 
Norman Diamond said:
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.
Click to expand...

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
 
Edward Diener said:
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.
Click to expand...

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
 
David said:
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.
Click to expand...

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
 
Tamas Demjen said:
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.
Click to expand...

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