Re: Disappointment in VC++ .Net in VS2008

On Dec 23, 10:20 am, Edward Diener
<eddielee_no_spam_h...@xxxxxxxxxxxxxx> wrote:
David Lowndes wrote:
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.

I agree, C++/CLI is a way better language than C# - and I could never
truly understand why Microsoft gave themselves the headache of
supporting 3 general purpose languages when 1 could have done it all.

.Net is supposed to be language agnostic as long as the language support
the CLR. This is a big part of Microsoft's selling point for it as
opposed to Java.

Since C++/CLI is Microsoft's own C++-like language for .Net they should
support it just as well as they support C# and VB .Net.

IMHO they made lots of poor decisions with .Net - but it's all water
under the bridge now - isn't it?

If you take a fatalistic attitude that what's done is done and can not
be corrected, then you are right. I do not agree. Technologies are
mutable and can always be changed for the better. Actually in only one
major area do i believe that Microsoft has made a large mistake in .Net,
which I won't go into now. But my OP was not about that, and the mistake
I see is not in .Net itself in not supporting C++/CLI as a .Net language
as it should be.



At least we know they now know that people use C++ for developing all
aspects of Windows applications in the native code area - let's just
hope they don't forget that!

I am also interested in Windows applications using .Net. Why should that
be slighted ? Microsoft has already had, through MFC which I dislike,
support for C++ Windows applications for over a decade and a half. I am
not interested in going back to that. But evidently Microsoft is
interested in forcing me to use that if I program in C++ or forcing me
to use C# if I move to .Net. That does not explain to me logically why
C++/CLI was created, except as a sop to C++ programmers while forcing
them to use C# instead.

Hi

Although, I can sympathise with the original OP regarding the apparent
re-focus by MS on pushing VC++ for native development, I actually
welcome the acknowledgement that most people view C++ as the tool of
choice for native development, rather than as a .NET tool. The .NET
and Java libraries are very comprehensive frameworks and from my
limited exposure to them, seem quite simple for a developer to get
familiar with (especially when compared to Boost or STL). But, not
all applications can accept the performance hit that comes with
programming to a virtual platform. I'm also not a big fan of MFC,
never have been, I use wxWidgets, but I may re-consider the new-look
MFC.

I would, however, be ***very*** disappointed if MS delay in adding
support for the TR1 extensions to VS2008. Once we have a C++ standard
which includes features such as a threading library, concepts,
reference wrappers and smart pointers, I think C++ will become a
suitable tool for a much broader range of applications, even without a
standard GUI library. I wouldn't be too surprised if we see some C#/
Java applications re-written in native C++, especially where there is
no need to be cross-platform. This is especially applicable in the
area where I work, derivative market-making systems. I'm convinced
there are rich pickings to be made by building a market-making system
in native C++ to exploit the poor performance of the plethora of
trading systems developed by the major banks in C#/Java over the last
few years - I'm actually hoping they keep the C#/Java systems running
just long enough for me to make enough money using my native C++
trading system.

So I wouldn't be too disappointed to see the de-emphasis of C++/CLI,
and consider the opportunities of having a C++ compiler equipped with
the TR1 extensions instead.

Cheers

.

Relevant Pages

  • Re: Is .NET going to be dropped by Microsoft?
    ... For line-of-business applications using .NET's paint optimization features ... >and developers influential in the decision process. ... Most Microsoft embedded device development has or is transtitioning to .NET ... > My sources are from some relatively large organizations such as Bank of> the West, Bank of America, SBC, ATI, and a few others -- from senior> management and developers influential in the decision process. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: porting from C++Builder
    ... the java was growing and, obviously, microsoft initially tried to ... that crowds of developers would rather stay and develop windows applications. ...
    (microsoft.public.dotnet.languages.vc)
  • Future of Risc OS
    ... serious developer of major new applications is taking time out. ... users who want to support continued development ... the risk off developers on larger projects. ... tell me this is the way to develop a player on a minority platform). ...
    (comp.sys.acorn.apps)
  • Re: .NET SUCKS --- READ FOLLOWING. MICROSOFT IS A SUCKY CO
    ... Tim did say that architects and developers should consider what ... If you free your memory - perhaps by following the disposable ... > I am huge supporter of each and every tech. developed from microsoft ... because not all applications require real-time behavior. ...
    (microsoft.public.dotnet.framework)
  • An open letter to the VB community
    ... the millions of developers who have been stranded by Microsoft and its ... refusal to continue support for Visual Basic 6. ... than 30,000 Visual Basic developers have joined the REALbasic ... If you didn't get a free REALbasic license, ...
    (microsoft.public.vb.general.discussion)
Quantcast