Java developer moving to Windows-Only apps: C++ or C#?

[steve.anon]

Hi I'm a Java developer moving to windows only applications. Of course
the first thing I thought was "well at least, without the VM now I can
write desktop applications that run real fast".

So I was happily heading to refresh my C++ memory and learn MFC when I
ran into this on Wikipedia:

".... applications written in Managed C++ have automatic garbage
collection and will run via the .NET virtual machine, just as
applications written in C# and Visual Basic .NET do. Additionally,
applications written in Managed C++ compile to CIL-Common
Intermediate Language-and not directly to native CPU instructions
like regular C++ applications do."

Now, it's my understanding that Microsoft is really pushing for all C++
programmer to use Managed C++, and that MFC, while still supported,
will not get too much spotlight on Longhorn. In fact I have read in a
few places that to benefit from the new Aeroglass/Avalon 'look and
feel' you will be pretty much forced to use Managed C++.

So... if you are using Managed C++ you are using a VM, so you basically
lose the 'traditionnal' advantage of C/C++ being 'faster' than C# or
Java. It's almost as if the only reason one would want to use C++ is
because they already know it, certainly not because it will provide
better performance on Longhorn. Basically, almost as if Microsoft was
providing "Backward compatibility".

If that's the case, then I suppose a Java guy like me probably will be
more at home with C#. But before I make the jump and invest a lot of
time and effort in this project, I'd like to ask this group their
opinion first.

I do find this very odd. I installed Paint .Net and noticed the whole
thing runs slow compared to say, Photoshop. It also took an awful lot
of memory for what it did. I can't really imagine Ms would want
EVERYONE to build applications that run within VMs, JIT or not. Sounds
horribly wasteful to me, especially since after all they do have
control over the platform.

TIA,

Steve.

[Kapil Khosla [MSFT]]

"Ioannis Vranos" wrote:

I think they must make their bug-reporting mechanism more open than what is currently.

Currently, we have a product feedback page (link below) where our deveopers
and testers look at the bugs opened by customers and address the issue as
soon as possible. We fix most of the legitimate bugs and give a workaround if
it is too late in the product cycle and we dont have resources to fix the
problem.

You can report any bugs you find at
http://lab.msdn.microsoft.com/productfeedback/

We highly appreciate customers finding bugs and reporting them. As these are
real world scenarios, they are always very high priority.

Thanks,
Kapil

[Arnaud Debaene]

John Gabriel wrote:

<sight> May I recall the good old Usenet proverb : DO NOT FEED THE TROLL
!!!!
Arnaud
MVP - VC

[John Gabriel]

MVP - Does this stand for Most Valuable Pawn?

I was not going to reply to this post but you are a troll! It's people like
you who have nothing to contribute, who know very little and who are good
Microsoft puppets. Carry on being a fine Microsoft troll - they may offer
you a job there soon some day. Don't bother responding, because I won't be
responding. I promise you.

"Arnaud Debaene" wrote:

John Gabriel wrote:

<sight> May I recall the good old Usenet proverb : DO NOT FEED THE TROLL
!!!!
Arnaud
MVP - VC

[William DePalo [MVP VC++]]

"John Gabriel" <Jo*********@di scussions.micro soft.com> wrote in message
news:D7******** *************** ***********@mic rosoft.com...

MVP - Does this stand for Most Valuable Pawn?
LOL.
Don't bother responding, because I won't be
responding. I promise you.

We can only hope.

Regards,
Will

[Edward Diener]

st********@gmai l.com wrote:

Hi I'm a Java developer moving to windows only applications. Of course
the first thing I thought was "well at least, without the VM now I can
write desktop applications that run real fast".

So I was happily heading to refresh my C++ memory and learn MFC when I
ran into this on Wikipedia:

".... applications written in Managed C++ have automatic garbage
collection and will run via the .NET virtual machine, just as
applications written in C# and Visual Basic .NET do. Additionally,
applications written in Managed C++ compile to CIL-Common
Intermediate Language-and not directly to native CPU instructions
like regular C++ applications do."

Now, it's my understanding that Microsoft is really pushing for all C++
programmer to use Managed C++, and that MFC, while still supported,
will not get too much spotlight on Longhorn. In fact I have read in a
few places that to benefit from the new Aeroglass/Avalon 'look and
feel' you will be pretty much forced to use Managed C++.

So... if you are using Managed C++ you are using a VM, so you basically
lose the 'traditionnal' advantage of C/C++ being 'faster' than C# or
Java. It's almost as if the only reason one would want to use C++ is
because they already know it, certainly not because it will provide
better performance on Longhorn. Basically, almost as if Microsoft was
providing "Backward compatibility".

If that's the case, then I suppose a Java guy like me probably will be
more at home with C#. But before I make the jump and invest a lot of
time and effort in this project, I'd like to ask this group their
opinion first.

C#, despite the name, is MS's "improvemen t" of Java. It has much more to
do with Java and its ideas than it does with C++. C++ is a language
still far in advance of Java or C#, despite all the hype for the former
languages. If you are used to Java, then learning C# will be a snap,
while using modern C++ idioms will probably be harder you. BTW, MFC is
very far from modern C++ and is a dinosaur waiting to die its natural
death despite all the people still using it.

Of course if you use C++, not only will you be using the best statically
typed language around but nearly all other statically typed languages,
as well as first-rate dynamically typed languages like Python and Ruby,
should be fairly easy to learn and use. C++ is still tops, and is the
language par excellence for the best of programmers. Java and C#,
although nice languages, offer nothing which C++ does not have, and will
still be catching up with C++ for years to come.

As far as .NET goes, a serious bug in net 1.0 and net 1.1 keeps C++
developers from writing normal C++ code in .NET assemblies. This has
been fixed in the next release however. Good luck !

[Edward Diener]

John Gabriel wrote:

Are you in for a nasty shock! VC++ 2005 is a disaster - at least from what I
have seen from the Express Beta Edition. Managed code is Microsoft's buzzword
for controlled memory management (garbage collection as in Java). Trying to
write even the most simple application is a Herculean task. Most of the
traditional C++ functions have been deprecated in favour of the 'managed
ones'.

Some facts I learned very fast:
- The Beta Edition crashes for no reason at all.

snip...

That's why it is called Beta.

[Patrick]

I am curious to see how internal product groups of Microsoft will handle this
'migration' from Unmanaged C to Managed C, most of MS' products are still
built on Win32 API such as Office, SQL Server and even Windows. .NET
libraries are mostly provided as a 'wrapper' to their Win32 interfaces for
ease of coding in .NET. Maybe we will get a better idea when VS2005 is
officially out later...
"st********@gma il.com" wrote:

Hi I'm a Java developer moving to windows only applications. Of course
the first thing I thought was "well at least, without the VM now I can
write desktop applications that run real fast".

So I was happily heading to refresh my C++ memory and learn MFC when I
ran into this on Wikipedia:

".... applications written in Managed C++ have automatic garbage
collection and will run via the .NET virtual machine, just as
applications written in C# and Visual Basic .NET do. Additionally,
applications written in Managed C++ compile to CIL-Common
Intermediate Language-and not directly to native CPU instructions
like regular C++ applications do."

Now, it's my understanding that Microsoft is really pushing for all C++
programmer to use Managed C++, and that MFC, while still supported,
will not get too much spotlight on Longhorn. In fact I have read in a
few places that to benefit from the new Aeroglass/Avalon 'look and
feel' you will be pretty much forced to use Managed C++.

So... if you are using Managed C++ you are using a VM, so you basically
lose the 'traditionnal' advantage of C/C++ being 'faster' than C# or
Java. It's almost as if the only reason one would want to use C++ is
because they already know it, certainly not because it will provide
better performance on Longhorn. Basically, almost as if Microsoft was
providing "Backward compatibility".

If that's the case, then I suppose a Java guy like me probably will be
more at home with C#. But before I make the jump and invest a lot of
time and effort in this project, I'd like to ask this group their
opinion first.

I do find this very odd. I installed Paint .Net and noticed the whole
thing runs slow compared to say, Photoshop. It also took an awful lot
of memory for what it did. I can't really imagine Ms would want
EVERYONE to build applications that run within VMs, JIT or not. Sounds
horribly wasteful to me, especially since after all they do have
control over the platform.

TIA,

Steve.

[Ioannis Vranos]

Patrick wrote:

I am curious to see how internal product groups of Microsoft will handle this
'migration' from Unmanaged C to Managed C,

Or better described, unmanaged code to managed code.

most of MS' products are still
built on Win32 API such as Office, SQL Server and even Windows. .NET
libraries are mostly provided as a 'wrapper' to their Win32 interfaces for
ease of coding in .NET. Maybe we will get a better idea when VS2005 is
officially out later...

They wrap existing functionality because it makes no sense to rewrite it from scratch, and
is also faster.

I am not sure what you mean by "handling", but in C++ both managed code and unmanaged code
can be compiled mixed. Thus existing projects written in native code can be extended with
..NET code, with the old code remaining unchanged.

[Carl Daniel [VC++ MVP]]

Ioannis Vranos wrote:

Patrick wrote:

most of MS' products are still
built on Win32 API such as Office, SQL Server and even Windows. .NET
libraries are mostly provided as a 'wrapper' to their Win32
interfaces for ease of coding in .NET. Maybe we will get a better idea
when VS2005
is officially out later...

They wrap existing functionality because it makes no sense to rewrite
it from scratch, and is also faster.

I am not sure what you mean by "handling", but in C++ both managed
code and unmanaged code can be compiled mixed. Thus existing projects
written in native code can be extended with .NET code, with the old
code remaining unchanged.

Visual Studio itself is a fine example of such.

The main IDE is written in unmanaged C++, while the tools that plug into
that IDE are (in vc2005) a mixture of unmanged C++, MC++, C++/CLI and C#
(maybe even some VB.NET and VB6 thrown in for good measure - I'm not sure).

-cd