Visual C++ Book
in [MFC]
|
Prev: DoModal Broken in Debug Mode in VS2005 SP1
Next: Default beep when clicking in list control on Vista
From: Ajay Kalra on 31 Mar 2007 13:09 > As I've said before, it isn't as easy as people think to create your first > WinForms app in C#. Its one or two clicks to create a simple C# Winform app. >There is enough new that you don't need to be tripping > over the eccentricities of C# (compared to C++) along with everything else. I think C++/CLI is significantly more complicated than C#. In C# there is no distinction between managed or unmanaged. > To a C++ programmer, C++/CLI is intuitive to read and write, with no > gotchas. Possibly true but my experience has been otherwise. >Just replace "new" with "gcnew" and '^' with '*' and you're done. Hmm.. what are those? Too complicated from a C# perspective :-) --- Ajay
From: David Ching on 31 Mar 2007 13:17 "Ajay Kalra" <ajaykalra(a)yahoo.com> wrote in message news:1175360972.586727.40860(a)l77g2000hsb.googlegroups.com... >>Just replace "new" with "gcnew" and '^' with '*' and you're done. > > Hmm.. what are those? Too complicated from a C# perspective :-) > LOL, there you go again pretending to be a clueless Java programmer who's never seen a pointer before, instead of the system developer expert you really are! Do you have dual personalities? ;) -- David
From: MrAsm on 31 Mar 2007 19:05 On Sat, 31 Mar 2007 16:10:08 GMT, "David Ching" <dc(a)remove-this.dcsoft.com> wrote: >As I've said before, it isn't as easy as people think to create your first >WinForms app in C#. I don't agree. I think it's very easy to build a WinForm app in C#, using e.g. Visual C# Express 2005. It reminds me to Visual Basic 6, but with the elegance and robustness of C# (more elegant, more robust than (Visual-)Basic). The not-trivial task could be the understanding of all the infrastructure code created by the IDE, but this could be ignored in a first development step. I think you can be productive also without this understanding. (Of course, I think that a professional programmer must then go more deep and study and understand also the infrastructure code, but this could be a second step.) Of course, if you are an experienced Win32/MFC programmer, you can do advanced things in MFC and it may be hard to do them in C#. But it is simply because you don't have enough training in C#/WinForm, not because C# is harder than C++/MFC (at least, I think so). >But really, C++/CLI is the best way for experienced C++ people to get >started with .NET. I like C++. But if I would like to do .NET programming, I would use C#. I think that C# is the first-class language for .NET (I would prefer C# also over the more verbose Visual Basic .NET). And, in fact, LINQ and WPF are C#-only: there's no support for them for C++/CLI. A problem with .NET could be the .NET framework size and deployment. But, on modern hardware, the 20 MB of .NET framework would not be a huge problem. Moreover, on Vista it seems that .NET framework is a part of the system, so there is no deployment problem. One of the positive aspects of "pure" C++ is that you don't need the ..NET framework: you can simply statically link with MFC and it's all right. But if I'd use C++/CLI, I think that I would need the .NET framework again, so I loose this no-.NET dependecy advantage of C++. Moreover, C++/CLI is non-portable, so I loose also the portability positive point of C++. For performances, I read that C# has around 98% the performances of C++. I believe that the memory manager of C# has been designed and developed by very bright people, and maybe they did a better job than what an average or beginner C++ programmer can do with my custom memory management in C++. Of course, a very experienced C++ programmer may need to write a custom memory manager for special purposes, and C++ is the tool to choose in this case. Moreover, I had the opportunity to read very interestings posts here (some posts by Joe Newcomer) about the importance of *architecture optimization*. i.e. it's more important to optimize the architecture, the data structures, and the algorithms, than single lines of code. And I believe that an O(n^2) algorithm written in C++ is slower than a O(n*log(n)) algorithm implemented in C# :) If I really need very high performance, I would use C/C++ and maybe optimize in assembly, but this would be in an inner loop executed millions times, something like this. I think that C++ has several advantages over C#, like better portability (e.g. it is possible to write a portable 3D engine or math library in C++, to run also on MacOS X or Linux), or like a huge existing code base and libraries already developed and tested. But e.g. if we consider a web app, the latency of the Internet communication is more important and has more impact than the performance gain of C++ over C# (or Java). (And C#/Java would offer also better security and robustness, like avoiding buffer overflows, memory leaks, etc.) On the other side, if I need to get values from a serial port or some other device with high transfer-rate, I would choose something like C/C++. Also, for embedded systems with low memory constraints, C/C++ is a better choice than C#... I believe that it all depends on the real problem you're fighting. I don't see programming languages as "religions". Programming languages for me are just *tools*. :) >BTW, C# is in no way "better suited for this kind of task." C++/CLI has >exactly the same capabilities as C#, and in fact more of them (e.g. better >finalizer support, increased performance). The only reason I am migrating >to C# is to be positioned to take advantage of WPF and LINQ which will not >be usable from C++/CLI. That and the whole C# ecosystem, with the great >refactoring tools, and the vast C# samples. I see a lot of new Windows projects requiring C# programmers, a lot of request of jobs to migrate existing Visual Basic 6 or C++/MFC code base to C#. It seems to me that the future of Windows programming is C#/.NET. However, I'm happy that Microsoft continues to support and develop MFC, becuase I think that if I don't want the big .NET framework loaded, or if I want to use existing C++ code and libraries (e.g. there are lots of C++ libraries, 3D engines, math libraries, etc.), C++ and MFC is a very good option to build software for Windows. MrAsm
From: MrAsm on 31 Mar 2007 19:10 On 31 Mar 2007 10:09:32 -0700, "Ajay Kalra" <ajaykalra(a)yahoo.com> wrote: > >> As I've said before, it isn't as easy as people think to create your first >> WinForms app in C#. > >Its one or two clicks to create a simple C# Winform app. This is true. > >>There is enough new that you don't need to be tripping >> over the eccentricities of C# (compared to C++) along with everything else. > >I think C++/CLI is significantly more complicated than C#. In C# there >is no distinction between managed or unmanaged. I do agree. And there are other simplifications of C# over C++: from the unified dot-notation (just "." and no more :: or -> or . ...) to automatic memory management, to properties, to built-in unified Unicode strings (no more TEXT()/_T(), L"...", WCHAR *, CHAR*, LPCTSTR, wchar, BSTR, CString, CString, CStringW, CSuperString :), no more memory leaks, etc. MrAsm
From: David Ching on 31 Mar 2007 20:18
"MrAsm" <mrasm(a)usa.com> wrote in message news:c6ot0390liv0iditikf9a7t84bd2463ls8(a)4ax.com... > On Sat, 31 Mar 2007 16:10:08 GMT, "David Ching" > <dc(a)remove-this.dcsoft.com> wrote: > >>As I've said before, it isn't as easy as people think to create your first >>WinForms app in C#. > > I don't agree. I think it's very easy to build a WinForm app in C#, > using e.g. Visual C# Express 2005. > > Of course, if you are an experienced Win32/MFC programmer, you can do > advanced things in MFC and it may be hard to do them in C#. But it is > simply because you don't have enough training in C#/WinForm, not > because C# is harder than C++/MFC (at least, I think so). > All I can tell you is my life experience. In 2002, we debated writing a control panel application for a widely deployed mouse/keyboard system in ..NET. We decided against the painful cries of the rest of the Engineering team that .NET was too immature at that point to risk the company bread and butter. But that is when I first started (trying to) learn C#. Fast forward to PDC 2005. I became convinced it was time to start to start learning .NET in earnest. I picked up some C# books and sat down to read them. There were so many peculiarties that it was like an American hearing South African English. It was English, but not that you would necessarily understand it. I ran the 2-click AppWizard you spoke of and created a C# app with a list box in it and could not fill it with anything. Then a couple months ago I read the Ivor Horton book, and lo and behold, I could actually write C++/CLI code that actually made sense the first time. My listbox filled with something. When I had ^ pointers to things, it was actually a pointer. When I used '::' it actually meant the namespace. When I created a destructor and finalizer, those ran without any shocks. I used the IPWorks POP3 component and replaced 20 lines of code with a couple lines of code that set a property and made one method call. Things really started cooking for me with C++/CLI whereas I went nowhere with C#. It seems other C++ programmers don't have the problem of picking up C# that I did and maybe wouldn't find C++/CLI to be the great learning tool that I have. But I'm curious, have you actually *tried* doing something non-trivial in C#, or have you just read about it? -- David |