 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / Managed C++ / May 2005Java developer moving to Windows-Only apps: C++ or C#?
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. > So I was happily heading to refresh my C++ memory and learn MFC when I > ran into this on Wikipedia: [quoted text clipped - 5 lines] > 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 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 > 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 [quoted text clipped - 38 lines] > > Steve. > 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? > 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?  Signatureharry 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 > > 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? 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. > > 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? > 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=alpha+group:microsoft.public.dotnet.languages. vc+author:vranos&hl=el&lr=&selm=uXUK%23%24WgEHA.2916%40TK2MSFTNGP12.phx.gbl&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 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 > > Probably much longer than you have been around Ioannis! > > I have been a developer over 20 years. I have several firsts to my name. [quoted text clipped - 19 lines] > > http://www23.brinkster.com/noicys/cppcli.htm > 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 [quoted text clipped - 4 lines] > 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 [quoted text clipped - 11 lines] > 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. > 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 <sight> May I recall the good old Usenet proverb : DO NOT FEED THE TROLL !!!! Arnaud MVP - VC 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. > <sight> May I recall the good old Usenet proverb : DO NOT FEED THE TROLL > !!!! > > Arnaud > 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 > 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 [quoted text clipped - 5 lines] > Some facts I learned very fast: > - The Beta Edition crashes for no reason at all. snip... That's why it is called Beta. > 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 [quoted text clipped - 27 lines] > 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 ! 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... > 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 [quoted text clipped - 38 lines] > > Steve. > 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. >> most of MS' products are still >> built on Win32 API such as Office, SQL Server and even Windows. .NET [quoted text clipped - 10 lines] > 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 Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.