MVP Award...
in [MFC]
|
Prev: CMenu class and menu object
Next: need some class help
From: Ajay Kalra on 26 Feb 2010 13:24 > But the younger engineers use the IDE and I am not going to discourage > them. They are amazed at how fast I program and how fast I swap things > around with macros, but but its foreign to them. They really don't > know the difference and they think it (IDE) is normal and I believe > that is what Microsoft is thinking is the market too. The trouble with this logic you are comparing an exprienced person, such as yourself with others who are rookies with IDE. IDE is very very powerful. You can have define any macros you want to do whatever you want. I have customized my keys to whatever I want, inclusing auto- checkout, comparisons, code insertions, debugging, code view etc. I would be surprised if IDE cant do what you do in the other tool. In C#, there is a tool called Resharper which is designed for such things. Equivalent to some extent in VC is Whole Tomato's product. -- Ajay
From: Hector Santos on 26 Feb 2010 13:45 Ajay Kalra wrote: > I used MFC for 10 years and have been using C#/.Net for over 4 years. > Startup time is probably an issue(not if you use NGEN) but thats no > reason to dismiss it. .Net is significantly ahead of older > technologies. Our apps are trading apps in real world where > performance is of extreme importance and it works fine. I did some work with TradeStation (Omega Research ) during the early 90s. Familiar with them? If I understand your usage, it is useful (become feasible today) to implement a "p-code", "jit" or scripting environment even for graphics. Scripting environments, as well as managed environments has become more feasible today, of course, because of the faster machines, including higher bandwidths for remote client/server frameworks. Of course, when selling a commercial product , it makes even more sense to have this level of flexibility. I think the world is still in a transition. To get a feel of the evolution, just look at our product history where we offered the following to access the mail system: - Console/Text based with ANSI/VT100 displays if enabled - Telnet or dialup (same interface) - RIP, now deprecated, it predated HTML and was considered the front runner when introduced and was the darling of trade shows. RIP was a ICON/GLYPH based tokens language that allow RIP terminals to show GUI. - MAPI Exchange, this allowed Outlook to display our group forums as folders on user machines. - Native GUI frontend with an MFC applet, still available http://www.winserver.com/public/wcnavigator.wct See below - RFC based NNTP protocol, POP3, IMAP - Online Web Mail - Flat Views - Threaded Views - Topical Views What I believe you will see more is a trend for vendors to provide their own Native GUI frontends for many times, including tech support services. This time they will use client-side technology such as Flash, FLEX and SilverLight and browsers HTML5. I am confident Google is moving this with with Chrome using a Chome OS based on V8 (server-side javascript embedded language). Microsoft with WP7 on the mobile side is .NET so WP7 Apps will be .NET based instead of Windows CE/MFC. There is another major reason for vendors to produce proprietary frontends - EOLAS has obtained a frivilous patent on "WEB 2.0" and has already began to sue major WEB 2.0 web sites. http://news.cnet.com/8301-30685_3-10368638-264.html Its a crazy frivolous patent, but if companies are not going to waste time fighting it, there only choose is to move to proprietary frontends and non-WEB 2.0 technology, such as FLEX, SilverLight, WPF. Of course, in the future this is not going to help the industry to single source their "Viewer" - like a browser with HTML does today. A new standardization is required by the big boys. HTML5 is suppose to provide this hope but I am not sure how the EOLAS patent relates to this. I have recently read a "blab" for a call for standardization on the Flex, SilverLight like front because it is pretty sure that the future will move more of the power requirements to the client - i.e. offline technology, which BTW, IBM has many patents already in the area of cached storage of the "resources." :) Go Figure. -- HLS
From: Hector Santos on 26 Feb 2010 14:21 Ajay Kalra wrote: >> But the younger engineers use the IDE and I am not going to discourage >> them. They are amazed at how fast I program and how fast I swap things >> around with macros, but but its foreign to them. They really don't >> know the difference and they think it (IDE) is normal and I believe >> that is what Microsoft is thinking is the market too. > > The trouble with this logic you are comparing an exprienced person, > such as yourself with others who are rookies with IDE. IDE is very > very powerful. You can have define any macros you want to do whatever > you want. I have customized my keys to whatever I want, inclusing auto- > checkout, comparisons, code insertions, debugging, code view etc. I > would be surprised if IDE cant do what you do in the other tool. > > In C#, there is a tool called Resharper which is designed for such > things. Equivalent to some extent in VC is Whole Tomato's product. Don't get me wrong. I agree with you. I'm among the exception than the rule. I am not a cut and dry person. Everyone has their reasons so I am trying to indicate one way is bad or the other. Personally personal. I do use the IDE more than I said I do. But its not my principle programming tool and only because I want things done fast. For example, if I wanted to write a quicky, maybe as an example for a post here, I pop up Qedit, hit ctrl ], and a C/C++ console outline. Type whatever, hit F9 compile and done. This is far slower than loading the IDE and a small hassle just to get a single file compile and link. I think now with the VS200x, if you do this, it wants to create project files, solutions files, output files, etc, just alot of overhead. Maybe there a way around that, I don't recall if I found that, but I haven't fully embraced VS200x to know for one main reason, we are not ready to complete to .NET. Everything we have is RPC, WIN32 and MFC. Millions of dollars invested over the years, including the packaging. Sure, we can put a label over the requirements copy on the box (.NET required), but overall the revamping is a major investment and in my MS did show signs of neglect towards long time developers. I personally believe Ray Ozzie is the blame and thats only probably because I have to blame someone :) Yes, I did like the C# editor features over the VB features. I love the idea of refactoring, or what that called "reshaper?" Same thing? Yes, the macros are possible with the IDE and I have used it. I guess probably if anything, is not wanting yet to retool the IDE with my long time productivity preferences especially since I wasn't fully committed to it. What didn't help was: - VS2005 was really slow in compiling. I spent a lot of time trying to figure that one out. - Intellsense was really slow, yes, got the old patch, I don't know if - Not having MFC class wizard support, - the Online Help was BROKEN, and thats probably because - I was FUMING with the idea that a IDE was not a "social networking tool" and I removed a DLL that was invoked for this in the IDE. I forget what dll it was, but its documented in the net as a way to effectively disable this "spy ware" The latter is extremely personal to me as a highly ethical engineer that has designed software that addressed high ethicals in social engineering and have probably lost millions if not billions because I am such a stickler for such strong engineering and privacy issues. I will probably say that this VS issue alone of having this "social help" thing in the IDE was the #1 reason I stayed around from VS and .NET. It bothers me a lot but I also grown weary and apathetic to the reality that users today don't care - its the "new normal." In fact, that apathy is shown by the fact that I began to install things, including VS2005 again to just LET It do its thing and not try to inference in how it suppose to work. That new "attitude" is needed today because many things today do not work without having what is expected enabled - like a web site that totally breaks done if you don't have javascript enabled or don't allow for some AD tracking company to be pinged! -- HLS
From: Joseph M. Newcomer on 26 Feb 2010 14:45 See below... On Fri, 26 Feb 2010 13:05:40 -0500, Hector Santos <sant9442(a)nospam.gmail.com> wrote: >David Lowndes wrote: > >>> Or the fact that they basically re-implemented what was already a flawed design. >> >> From a couple of the issues I noticed, I have a suspicion they >> reimplemented it from an early version before bugs were fixed (a long >> time ago). > >Personally, I have held off from upgrading from VS2005 and was >"excited" to hear that VS2010 was the new "VC6", that microsoft took >notice of the long time investments in MFC and long time developer >neglect during the last decade. > >But it seems the same of issues (and possible worst) has continued. I >read the project manager blog and I believe he was misguided taking >"reviews" from testers who I honestly believe they don't really want >to tell him the bad news, so they tell him "its better than the beta" >and believes thats OK! I don't think that is the real test. > >I'm a speed demon, power programmer. I really only used the IDE to >design the GUI and outline of events. From there, I use my trusted >Qedit (renamed to TSE) power programmer editor >(http://www.semware.com) of 30 years - the BEST in the world. :) I >need fast loading, no slow downs in typing, and fast macro programming >for patterns. I don't need intellisense slowing me down - its terrible. **** I'm with you on that. We can debate whether qedit (which I've never used) or Epsilon (which I've used for 22 years) is the "best" editor, but the key thing Microsoft COMPLETELY overlooked: editors are not a technology, they are a religion. The ONLY sane approach was to provide an editor-friendly API to encourage third parties to produce editors. This includes all the Intellisense, highlighting, etc. features. They simply don't understand this rather simple point, which everyone else has deeply understood for YEARS. You like qedit. I like Epsilon. People actually think vi is a text editor. It DOESN'T MATTER! Key here is that Microsoft is largely clueless about what constitutes a text editor, thinking that what they have is the only editor that could make sense. They are wrong. I use the VS IDE editor for debugging, for making trivial syntax changes (misplaced comma, missing or extra right paren, fixing my SetWindowTxet and GetWIndowText typos, and THAT'S IT! I would NEVER consider using it to create a program! It is so weak as to be nearly unusable, and it is not user-extensible in the way a truly user-extensible editor MUST be to be acceptable! When I teach classes, I keep vim (the open source VI editor) on a USB key, and anyone who wants to use it, I plug the key in and install it for them. A nontrivlal number of my students like this fact. No matter WHAT the build, it will not be acceptable to the people who know what REAL text editors look like. I'll trade off ALL of the syntax checking and Intellinonsense for the power of my editor. [Actually, I already do that]. **** > >But the younger engineers use the IDE and I am not going to discourage >them. They are amazed at how fast I program and how fast I swap things >around with macros, but but its foreign to them. They really don't >know the difference and they think it (IDE) is normal and I believe >that is what Microsoft is thinking is the market too. **** I find the attitude that "we know best how you should use your primary interface to the computer, and screw you for believing otherwise" to be inappropriate. **** > >I personally believe a big part of the slow down has to do with >security related stuff and all the new layers of dlls and sub-systems. > >VS2005 compiles 50%-250% slower for the same code. I dug into this >with depends and found that during compile it the Crypto sub-system is >ALWAYS invoked and this is where there are compiler delays. But >surprisingly, when I called this with VC6, it did the same thing but >was FASTER. **** Part of the problem of VS2005 was it was the first really-first-rate C++ language implementation. They had a few problems with the compiler, including its performance, and most of those were fixed by VS2008, which is what I mostly use today. One reason VS6 was faster was that it was both incomplete and wrong. It couldn't compile even its 1998-contemporary C++ language (serious conformance issues, especially in templates). Those fixes did cost performance. But Microsoft has been very sensitive to this issue and has addressed this problem, very intensely, in subsequent releases. They also have ported some 64-bit compiler components back to the 32-bit world (read the VS2010 "What's new in VS2010" and these represent performance improvements as well. VS2005 was definitely a slow compiler compared to VS6. I have not done the measures with VS2008 or VS2010, but I know that performance is a continuing issue and will continue to improve. **** > >I just did a quick timing test with a 1 line hello world: > > XP box source code across the LAN: > > VC6 : ~700ms > VS2005: ~1600ms **** These times are too small to matter, and the source example is too small to matter. Key performance comes with looking at 100SLOC-sized apps. For example, separate compilation overhead in VS2005 is substantially higher, but when amortized over 500 source files it doesn't show up as badly. Part of this is a richer .pch format necessary to support templates properly, or so I was told. But right now, even for large systems, 2005 is measurably slower than VS6. **** > >When I first encounter this, I had a 1G XP box. I was seeing 1:5 >compiler speeds. Adding another gig (2GIG total) with some registry >changes to fine tune the Paging system, it was more acceptable now, >but still slower. **** The VS2005 compiler is also substantially larger than the VS6 compiler. The price of doing C++ right. **** > >When I measured the time differences via DEPENDS, the time was only >lost with the crypto sub-system which was invoked for some reason, all >other times were the basically the same. **** The use of the crypto subsystem is definitely weird. I wonder what they are checking? Llicense validity? No idea. joe **** Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 26 Feb 2010 14:50
OpenGL is a contemporary standard, and unlike DirectX, is both platform-independent and has a large body of non-Microsoft users who are expert in it. The last I looked at driver certification, a device driver had to support GDI, DirectX and OpenGL to get logo certification. ..NET doesn't solve the 3D problem if you are trying to port your visualization software across. Far too slow. I know some people who are implementing parts of their rendering software with the 3DNow! (AMD) extensions as replacement modules in some of the OpenGL library. None of these people, who are desperately concerned with graphics performance, would consider WPF or .NET a suitable replacement. [Note: I really like programming in C#, but I don't have a customer base that uses it] joe On Fri, 26 Feb 2010 09:43:20 -0800 (PST), Ajay Kalra <ajaykalra(a)yahoo.com> wrote: >On Feb 26, 12:21�pm, "James Juno" <j...(a)noplace.fake> wrote: >> Funny thing. �My shop specializes in scientific data visualization using >> OpenGL. �We've replaced some of the MFC controls with in-house (and >> superior) equivalents rendered in an OpenGL context. �I guess in a sort of >> bastardized way, this is similar to WPF. �Still, we're unlikely to consider >> using WPF anytime in the near future. �Our toolset is too highly integrated >> into the more battle-tested and mature (or, depending on your agenda, >> "legacy and obsolete") technology. > >I am certain I will call OpenGL as obsolete technology(May DirectX is >now better; dont know). There is no agenda here but for vanilla UI >apps not requring any specialization, .Net is far superior IMO. Even >with apps requiring specialization, .Net can coexist comfortably. > >The problem is not about embracing a newer technology, its about the >cost of migrating over existing system to newer one. Normally there is >no reason to do it and its a waste of resources without any real >benefits. However for new apps, these rules dont apply. Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm |