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.

 

[William DePalo [MVP VC++]]

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."

Right. Note that in the .Net case IL is never executed. It is either
just-in-time compiled to machine code or it is pre-jitted and stored in the
Global Assembly Cache.

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.

I think that the operative word is "done". MFC is done in the sense that we
probably won't see much in the way of enhancement or extension though it may
be updated to do some things better, like perhaps interoperating with the
..Net framework.

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++.

I _think_ that's the case.

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".

Well, MC++, soon to be C++/CLI when VS2005 is released, is a special case.
With it it is possible to build an application that contains both managed
and unmanaged code even within the same module. You will appreciate this
feature if you have ever had to use JNI to craft a class with native
methods. It is a lot easier than that, IMO, though there a still enough
details to make it interesting. It is not an either/or proposition.

If that's the case, then I suppose a Java guy like me probably will be
more at home with C#.
Yes.

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.

It is a crap shoot. You places your bets and you takes your chances. I'm
not sure what to make of it but there seems to be quite a lot more traffic
in the groups that focus on .Net groups than the native side of the house.

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.

In my perfect world everyone would be smart enough and ambitious enough to
do things the right way and able to use C++ without doing harm to
themselves. Sadly, there are not a lot of those people around.

I can't help but think that the situation is a lot like the one in the early
90s when the decision was to choose DOS or Windows. Windows was slow and
bloated (by comparison) and almost no one used assembly language which was
not at all uncommon under DOS. And you didn't get to do everything
yourself - no more INT 21H or writing app-specific print drivers - but
instead on had to use the platform.

Unfortunately for you though, no one can predict when the future comes or
what it will bring.

Regards,
Will

 

[Guest]

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.
- Compiler output is not trustworthy (It may report that the compilation was
unsuccessful but it was in fact successful). There is a serious problem with
the compiler not knowing the status of certain files and resources, i.e. it
may not compile your code because it thinks a resource/file is locked when
in actual fact it is not.
- Using managed code and handles is very difficult. The ^ (handle to object)
can only be used with managed objects.
- The Document Explorer (MS help feature) is vague, unorganized and full of
bugs (back and forward browser buttons don't work consistently).
- You may lose parts of your 'solution' (project) by just clicking
accidentally in
one of your source files. An error window pops up and tells you to restart
the
application in order to rebuild the solution. A million other windows pop up
asking if they can send bug reports to MS. It is a joke.
- You may not be able to monitor certain variables because the compiler thinks
they are out of scope.

Actually I could go on and on but I see no sense in it. I have already
uninstalled the
VC++ Express Edition and will not look at this again until MS brings out a
version which is truly 'beta'. The version they claim is beta is in actual
fact more of an 'omega' version which they are bringing to 'beta' phase by
exploiting newsgroup users and the public in general as an unpaid Quality
Control department.

Join the ranks of all of MS unpaid software developers/testers !!

Good luck.

John Gabriel

 

[Ioannis Vranos]

Are you in for a nasty shock! VC++ 2005 is a disaster - at least from what I
have seen from the Express Beta Edition.

Have you tested Beta software before in your life?

 

[harry_bosch]

Have you tested Beta software before in your life?

I have, I'm still running VS.NET 2003. That's still beta, isn't it -- or
did they fix all the bugs and somehow I missed it?

 

[Guest]

Probably much longer than you have been around Ioannis!
I have been a developer over 20 years. I have several firsts to my name.
Was around before the first PC or Microsoft appeared.
Started off as a COBOL programmer writing software on punched cards.
Have I ever tested 'beta' software in my life? Hmmm, let me see? Yes, I
think I have.

 

[Guest]

Harry,
VC.NET 2003 is only starting to get close to 'beta' now. It was
'omega' when you got it. With the help of fine programmers like you and the
public, MS has outsourced quality management to the public which it does not
even pay for!

If MS was to pay $1000 for each bug reported, I have no doubt we would be
multimillionaires in no time at all.

John Gabriel

 

[Ioannis Vranos]

Probably much longer than you have been around Ioannis!
I have been a developer over 20 years. I have several firsts to my name.
Was around before the first PC or Microsoft appeared.
Started off as a COBOL programmer writing software on punched cards.
Have I ever tested 'beta' software in my life? Hmmm, let me see? Yes, I
think I have.

OK, just checking out. Myself think that these releases should be called alphas and not betas:

http://groups.google.com/groups?q=a...=uXUK#[email protected]&rnum=1


My personal opinion is that their primary purpose for general availability of the Express
Beta versions is not Beta testing but technology preview.

Regarding VS 2003, I think it is stable, so I can't understand any VS 2003 instability
allegations (by anyone, I do not remember whom).

Also Beta 2 is much more stable than Beta 1, so I do not think Beta 2 instability is any
indicator of the final product instability.

Regarding "handles" etc, perhaps this page of mine may provide some insight:

http://www23.brinkster.com/noicys/cppcli.htm

 

[Guest]

Hi,
Traditionally, beta is the second phase of software release and usually
the last one. In the 1980s we would talk about it the other way around, i.e.
alpha is the version before production. What this means is that 2 testing
phases were not necessarily enough for the
quality management. It would generally be agreed that n phases were required
and then a countdown would begin so that alpha would be the most stable. Each
phase would have its own scope and objectives. By the time you reach alpha
phase, there should be no show-stoppers remaining. As an example, this VC++
2005 express edition has numerous show-stoppers. In fact, it is unacceptable
for commercial use. Under no circumstances should an IDE terminate abruptly
with loss of files and data. At the very least, the compiler mechanism should
report accurately the results of compilation. The express edition allows you
to perform a build without any changes given a faulty compilation. It
subsequently reports no compile errors. How can this be? Okay, so customer
would have to build any project TWICE just to be sure that it either compiled
or did not compile correctly. The documentation is another issue - I know
that it can't be 100% bug-free but there are levels of acceptance. This
version does not even pass the first level in my opinion. The IDE is sooo
cluttered, soooo complicated - in trying to do too much, MS ends up doing
very little and annoying those whom it's trying to satisfy. There is just too
*much* going on in Express edition.

I don't have a problem with managed code except that that I don't like it
stuffed down my throat. Am open to new ideas and advancement but it must
work. I think the first version of DOS probably had far less errors than
Express edition.

The good ideas: I like the look and feel of the IDE as far as the Toolboxes,
Property Sheets, etc are concerned and also all the auxiliary code generated
automatically. It makes for less coding but becomes far more complex, slower
and takes away more control from the programmer. Good programming is not made
possible by managed code but rather by disciplined programmers. Taking away
control from the programmer is not the solution.
And what's this thing with new terminology: 'solution' etc? Why not just
stick with the original names? I have not worked on VC 2003 but I bet a
conversion from this to 2005 will not be a straightforward task either.

One last thing: A lot of bugs go unreported because programmers find
workarounds and MS takes too long to resolve the issues. In my experience, MS
often does not even respond to my bug reports. They are simply never fixed.
If there is a workaround you are expected to use it.

John Gabriel

 

[Ioannis Vranos]

Hi,
Traditionally, beta is the second phase of software release and usually
the last one. In the 1980s we would talk about it the other way around, i.e.
alpha is the version before production.

I had alpha as the first phase in mind, when I was talking about that.

What this means is that 2 testing
phases were not necessarily enough for the
quality management. It would generally be agreed that n phases were required
and then a countdown would begin so that alpha would be the most stable. Each
phase would have its own scope and objectives. By the time you reach alpha
phase, there should be no show-stoppers remaining. As an example, this VC++
2005 express edition has numerous show-stoppers. In fact, it is unacceptable
for commercial use.

I agree. MS general jumps to "Beta" terminology directly and calls "Release Candidates"
(or Final Betas) what should be called as Betas.


In any case, I expect the final product to be stable when it is released, and if you want
to see real "Beta", I think you should wait for the first release candidate whenever that
happens.

Under no circumstances should an IDE terminate abruptly
with loss of files and data. At the very least, the compiler mechanism should
report accurately the results of compilation.

I know, myself uses mainly the compiler of these "Betas" in the command line.

The express edition allows you
to perform a build without any changes given a faulty compilation. It
subsequently reports no compile errors. How can this be? Okay, so customer
would have to build any project TWICE just to be sure that it either compiled
or did not compile correctly. The documentation is another issue - I know
that it can't be 100% bug-free but there are levels of acceptance. This
version does not even pass the first level in my opinion. The IDE is sooo
cluttered, soooo complicated - in trying to do too much, MS ends up doing
very little and annoying those whom it's trying to satisfy. There is just too
*much* going on in Express edition.

I don't have a problem with managed code except that that I don't like it
stuffed down my throat. Am open to new ideas and advancement but it must
work. I think the first version of DOS probably had far less errors than
Express edition.

Again, I think you should wait to see how the final version will look like.


In another matter, Express editions are aimed for students/hobbyists and are not aimed to
professional development. I am talking about features here and not about stability.

The good ideas: I like the look and feel of the IDE as far as the Toolboxes,
Property Sheets, etc are concerned and also all the auxiliary code generated
automatically. It makes for less coding but becomes far more complex, slower
and takes away more control from the programmer. Good programming is not made
possible by managed code but rather by disciplined programmers.

As always. I think .NET however is much high-level and more convenient than MFC, Win32,
COM, etc. Plus it provides the same API for all languages and thus you do not have to
learn a new Windows API for another language.


Also it enables different parts of an application to be written in different languages by
being shared as managed dlls.

Taking away
control from the programmer is not the solution.

Regarding C++, I see no loss of control. May you provide an example?

And what's this thing with new terminology: 'solution' etc? Why not just
stick with the original names? I have not worked on VC 2003 but I bet a
conversion from this to 2005 will not be a straightforward task either.

I am new to Windows programming (learning .NET directly), so I do not know the previous
VC++ terminologies.

As far as I can understand, a solution is a project containing one or more projects. In VS
2003 you can join different projects in one solution and compile them together (apart from
VC++ ones, perhaps it can be done mixed with VC# projects etc, apart from the dll approach
that I mentioned above).

One last thing: A lot of bugs go unreported because programmers find
workarounds and MS takes too long to resolve the issues. In my experience, MS
often does not even respond to my bug reports. They are simply never fixed.
If there is a workaround you are expected to use it.

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

 

[Guest]

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

 

[Guest]

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.

 

[William DePalo [MVP VC++]]

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]

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 "improvement" 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]

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.

 

[Guest]

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...

 

[Ioannis Vranos]

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]]

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