Re: The wonder about .NET supporting or not C++ is about to turn to certainty.

Tech-Archive recommends: Speed Up your PC by fixing your registry

From: David F (David-White_at_earthlink.net)
Date: 06/18/04


Date: Fri, 18 Jun 2004 06:26:38 GMT


"Carl Daniel [VC++ MVP]" <cpdaniel_remove_this_and_nospam@mvps.org.nospam>
wrote in message news:O$vxRvcUEHA.4048@TK2MSFTNGP12.phx.gbl...
> Responding to some of the argument:
>
> <pointless ad hominem stripped>
>
> > Right from the very beginning, 1st paragraph from the intro to [1]
> > (page iv), it says: "C++ developers need not feel left out,.Visual
> > C++ .NET make C++ a first class member of the .NET family of
> > programming languages".
>
> There's no denying that C++ is a second-class citizen in the .NET world
with
> Visual Studio .NET 2003. This situation is changing RADICALLY for the
> better with Visual Studio 2005.
>
I never heard that the standard C++ has a second meaning to the word class -
"first class", "second class", etc.
So far I knew only one "class", the standard C++....

> > Page [1].287: "In contrast to most other GUI libraries, Windows Forms
> > can be used from any .NET language, and you can now easily build
> > mixed-language graphical applications." This is as blunt lie as
> > blunt can be.
>
> Rubbish. Windows forms CAN be used from any .NET language. The fact is,
> it's much easier to use from some .NET languages than others. You can, in
> fact, easily build mixed language graphical applications. You might not
be
> able to easily mix the parts in some particular way that you desire, but
> then the claim wasn't that you can just mix things willy-nilly and
> everything will just automagically work.
>
I don't follow what you mean by "...but...wasn't...willy-nilly". Either I
can use the Forms Designer (FD), with C++, THE C++ or not.
For example, the first thing the FD does is creating a small source file
called Form1.cpp.
If I just want to add to the top of the file, the statement:
    using namespace std;

I can't do it with all the ramifications. The "C++ compiler" comes back with
the following error message:

Form1.cpp(7) : error C2871: 'std' : a namespace with this name does not
exist

Since you know that "Windows Forms can be used from any .NET language", can
you tell HOW can it be used with C++?
Can you tell which document specifically documents this subject? If you
mention the magic acronym MSDN, please where in this endless maze.

> > Page [2].116: "You cannot write templated code with managed types
> > because .NET does not currently support generic programming."
>
> That's coming in VS 2005.
>
> > It is indeed very
> > plausible that the story is that C#, its real main goal is to fend
> > off C++, the same way as they tried to do with Java. If I buy a
> > compiler for C++, in which its documents has virtually nothing to do
> > with ISO C++ but a lot with VB, C#, "Managed" C++ which is a nice
> > word for a propriety, non portable C++, ripped off from its main
> > powers - and the WAY it is done, that is insidious. And is not a C++.
>
> Also changing radically in VS 2005. Managed Extentions for C++ (not
> "Managed C++") is much like working with Java through the JNI interface -
> it's a way to get your foot in the door, but it's painful and ugly
(although
> not as painful and ugly as JNI, in my opinion). You're very remiss to
> realize that "Managed Extensions for C++" are true extensions, done in the
> hideous and unusable way that the "pure C++" community would have: with
> grotesque __keywords and no real unification between the typesystems.
>
> > If a responder tells me that the advantage of C# is that it is
> > simpler than C++, what kind of a claim is this? What can I say? Don't
> > use the parts of C++, which are too complicated. Use it at the level
> > you feel comfort with. You don't have to use all the features. There
> > are features, that even though I have no difficulty with using them,
> > I don't use because I decided that I have better alternatives in the
> > language. That is why they have vanilla and chocolate.
>
> C# is a language aimed at a different audience than C++. It's simply not
> sufficient to say "only use the parts of C++ that you understand" when C++
> gives you more than enough rope to hang yourself in so many ways. Lack of
> automatic memory management, undefined behavior lurking around every
corner,
> implicit (and sometimes dangerous) type conversions at every turn. It's
> simply not possible to use a subset of C++ safely unless you've learned
> enough about the language to avoid the minefields (and most programmers
> working in C++ never learn those lessons thoroughly even after years of
> active practice).
>
> > And, if some of the responders in the chain of the 1st thread wrote
> > that he program in C/C++ "all day long w/o a problem", I have no
> > problem to believe him. Especially if that program all it does is
> > writing continuously "Hello World!" to a console. You need to
> > elaborate more.
>
> Your dramatic conclusions wear a little thin on the reader, but surely you
> realize that you're not expressing any kind of conclusion, but rather a
> sentiment, formed from a position of ignorance and confusion. It's not
> ourageous to estimate that far in excess of 99% of all commercial windows
> applications are written in C++. And a huge percentage of those are
written
> using Visual C++. And a large percentage of those are written without
using
> MFC.
>
> -cd
>
>



Relevant Pages

  • Re: subroutine stack and C machine model
    ... Hardly matters -- the type rules predate the standard by years. ... was defined as I have said to protect the profits of vendors. ... programmers and as such did a far more valuable service. ... how dare they come up with a common language definition so that people ...
    (comp.lang.c)
  • Re: subroutine stack and C machine model
    ... If you are referring to left-to-right evaluation, ... determined by the programmers of compilers...for the same reason that ... obsolete language APL enforced right to left evaluation. ... each compiler's choice was a defacto standard. ...
    (comp.lang.c)
  • Re: (Prolog + LISP + Erlang) with integration issues versus C++
    ... >> they will write idiomatic lisp so soon after learning it. ... >> Learning the language on the job is not a recipe for good maintainance. ... > programmers. ... standard, but it's been extended so heavily it may as well not be. ...
    (comp.lang.lisp)
  • Re: subroutine stack and C machine model
    ... It is a fact that the C language has been defined by the ISO C standards ... A mistake has been certified standard for too long. ... I've known plenty of good programmers who have switched to C from other ... Microsoft compiler used Int precision, ...
    (comp.lang.c)
  • Re: Is C99 the final C? (some suggestions)
    ... >> because the ANSI standard obsoleted them, and everyone picked up the ANSI ... > fixed by using another language. ... programmers managing the meaning of the symbols for more generic operators. ... According to a paper by Intel, widening multiply accounts for something like ...
    (comp.lang.c)