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: MrAsm on 1 Apr 2007 06:06 On Sat, 31 Mar 2007 20:47:09 -0700, "Tom Serface" <tom.nospam(a)camaswood.com> wrote: >MrAsm, > >One of the "good" things about MFC is that it has, for the most part, stayed >compatible with previous versions over the years. I do agree. Backward compatibility in general is an important merit of Microsoft. MrAsm
From: MrAsm on 1 Apr 2007 06:20 On Sun, 01 Apr 2007 04:05:29 GMT, "David Ching" <dc(a)remove-this.dcsoft.com> wrote: >OTOH, I am reading Advanced C# by Trey Nash which tells of best practices, >and there is a TON of stuff to learn regarding IDisposable, threading, >exception handling, etc. before one can claim to be proficient in C#. I believe that claiming to be proficient in C# and doing *advanced* stuff in C# is absolutely not trivial, and requires studying and coding. C# is not VisualBasic6++ ;-) MrAsm
From: David Ching on 1 Apr 2007 09:29 "MrAsm" <mrasm(a)usa.com> wrote in message news:gg1v03l392vg71ngr8mnvkl8648o7gl3tv(a)4ax.com... > I believe that claiming to be proficient in C# and doing *advanced* > stuff in C# is absolutely not trivial, and requires studying and > coding. > Yes, it's much like C++, MFC, and Win32! We still have to worry about things on the level of Win32 (when do we use SendMessage and when do we use PostMessage) and MFC (storage of temporary objects), but all these things are different. BTW, I misnamed the title of the book. It is Accelerated C# 2005 by Trey Nash. > C# is not VisualBasic6++ ;-) > No, but C# and VB.NET are so similar, it is said there is only one major language for .NET, and that language has a syntax variation! VB implies simplicity, but that is not always the case. Cheers, David
From: David Ching on 1 Apr 2007 09:34 "MrAsm" <mrasm(a)usa.com> wrote in message news:sh0v03h73ibomjik1hde71tnjo22mmn03k(a)4ax.com... > I do agree. > Backward compatibility in general is an important merit of Microsoft. > My viewpoint is that Microsoft isn't very concerned about backward compatibility at all, and even less so now. VC2005 is very different in terms of the runtime redist, the manifests, breaking changes to C++ code, etc. Their SxS DLL mechanism makes it possible for the Windows loader to run *your* app with *their* new DLL's whether you approve it or not, breaking the original spirit of SxS. .NET 2.0 has breaking changes as well. I would say the reason MFC has backwards compatibility is there hasn't been any forward innovation in years! It is such a lightweight wrapper around the OS, and incompatibility at the OS level really shines through. And since it's so lightweight, there isn't much chance for it to become incompatible. -- David
From: David Ching on 1 Apr 2007 09:39
"MrAsm" <mrasm(a)usa.com> wrote in message news:ccvu03tefvaukbrqdvbtcjmaanjt3r842m(a)4ax.com... > no, I'm sure I don't have the same experience and knowledge of C# that > you have. I'm just learning C# writing simple test apps (I like > learning in small pieces), so I didn't write anything non-trivial in > C#. I'm still in learning mode, and in fact I'm trying the VC#2005 > Express (a great gift by Microsoft to C# learners!). > Oh, OK. C++/CLI was the first way I found to create a working .NET app I use every day, so that's why I like it so much. > I respect your opinion that you like differentiating between instance > data member (.), pointed instance data member (->), and namespaces > (::). To all of us C++ programmers, it seems very clear because we are > used to that for years. But I think that the "spirit" of C# is very > different from the spirit of C++, I think that the spirit of C# is > about *simplification*, like Java. > > Of course, there are also some negative points about that. > For example, I like the deterministic finalization of C++, i.e. that a > destructor is automatically called when a function/method/block is > terminated ("}"). > So, if I access a resource e.g. a file with a File class with a > destructor that closes the file, I know that the file is closed (the > resource is released) when the block ends. > On the other side, it seems to me that I have to force the resource > release in C# (something like explicitly calling a method like > File.Close). I read about this IDisposable interface, but I did not go > very deep with it. > > However, I believe that, when memory constraints or resource > management do matter, when top performance is a must, etc. - as I > wrote in another post - C++ is the way to go. But, in these cases, I > would also not consider the managed world of .NET, but simply go > *native* with C++ and MFC. > If Xaml is successful, we will soon see many .NET front-ends, perhaps written in Orcas and Orcas+1. -- David |