TextOut() to a DialogBox ???
in [MFC]
|
From: Geoff on 24 Mar 2010 18:53 On Wed, 24 Mar 2010 15:39:26 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message >news:ufF$nt3yKHA.928(a)TK2MSFTNGP05.phx.gbl... >> Peter Olcott wrote: >> >>> "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >>> message >>> news:ndgkq5lbilsibpqql11bi0d0tp6b6psl6q(a)4ax.com... >> >> >>>> If you want text on a dialog box, place a static control >>>> there and use SetWindowText to >>>> tell it what to display. >>> >>> I don't think that will work because I need to specify >>> every detail of the text, its font, foreground color, et >>> cetera. In any case this is all moot now anyway. I am >>> simply bitblt-ing my memory bitmap to the window. >>> >>>> Developing the style of writing directly to a dialog box >>>> surface will eventually uncover a >>>> large set of problems, none of which you want to deal >>>> with. >>>> joe >>> >>> This is only for internal testing purposes. >> >> Then even more the reason to just use the IDE and controls >> as to not waste time learning something you will never use >> anyway - like Intel Chip Caches. :) >> >> -- >> HLS > >Here is an interesting note that I don't understand. A >slight revision (to make it a little less CPU intensive, >thus more memory intensive) only actually achieves 21 MB per >second of the 12 GB / second maximum RAM speed. (RAM speed >reported by MemTest86). > >const uint32 size = 100000000; >std::vector<uint32> Data; >uint32 Max = 0x3fffffff; > > >void Process() { > clock_t finish; > clock_t start = clock(); > double duration; > uint32 num; > for (uint32 N = 0; N < Max; N++) > num = Data[num]; > finish = clock(); > duration = (double)(finish - start) / CLOCKS_PER_SEC; > printf("%4.2f Seconds\n", duration); > } > >Another thing that I don't understand is that it crashes >when > num = Data[num]; >is replaced by > num = Data[N]; > Two bugs exist. 1. You never initialize num, so executing num = Data[num] will access a garbage address in debug mode and will attempt to read Data[0] in release mode since the OS will zero-fill num for you. 2. You never resize the vector space "Data" before you attempt to access it. Data.resize(Max);
From: Peter Olcott on 24 Mar 2010 18:58 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:5o0lq5hiiub6le7r305816093qruo9qrr9(a)4ax.com... > See below... > On Tue, 23 Mar 2010 23:09:05 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: > >> >>"Liviu" <lab2k1(a)gmail.c0m> wrote in message >>news:OypYNBwyKHA.4492(a)TK2MSFTNGP05.phx.gbl... >>> "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message >>> news:Uoudnfsmrcno5TTWnZ2dnUVZ_vydnZ2d(a)giganews.com... >>>> >>>> http://groups.google.com/group/microsoft.public.vc.mfc/msg/2aa003e71f5a1b38?hl=en >>>> It is the CDC that has the default bitmap. >>> >>> The HDC, to be precise. >>> >>> Anyway, that is very different from what you said, then >>> misattributed >>> to Joe for having said. The distinction was the point of >>> the exercise. >>> http://groups.google.com/group/microsoft.public.vc.mfc/tree/browse_frm/thread/c84953c13066a4f3/4b4e98102ea69979?hl=en&rnum=11&_done=%2Fgroup%2Fmicrosoft.public.vc.mfc%2Fbrowse_frm%2Fthread%2Fc84953c13066a4f3%3Fhl%3Den%26#doc_4b4e98102ea69979 >>> >>> >>> >> >>Personally I really hate dealing with tedious little >>details, the only reason that I can be good at software >>development is my continued focus on the big picture gist >>of >>things. This makes me very good at architectural (and >>other >>levels of) design, and lousy at debugging someone else's >>code. > **** > If you hate dealing with tedious little details, you are > in the wrong profession. > > Seriously, if you look at what makes an MVP, we all are > obsessed with making sure those > tedious little details all work correctly. Just read > anything Tom Serface, or Giovanni > DiCanio, or I write, or any other MVP,, and all we're > discussing are the fiddly little > details. Big picture is cool, but what makes it WORK are > all those fiddly details. And > in 47 years of programming, in a variety of languages on a > variety of platforms, I've > found that this is the difference between the successful > programmer and the wannabe; the > successful programmers know all the fiddly little details > that make things really run, and > run right, and run optimally, in whatever environment they > are working in. > > I became an expert in Chained Channel Control Words on the > IBM/360 architecture. I could > write entire programs in CCWs. I could make I/O devices > stand up and tapdance. > > I knew infinite details of the PDP-11 Unibus protocol. I > could tell you more about the > PDP-11 interrupt system than most people wanted to hear. > > One day, I worked with another guy at CMU and we > deep-sixed the high-bandwidth > communication project by reading the schematics and > demonstrating that as designed the > device would deadlock and hang under certain timing > conditions that could not be > controlled and predicted. This saved tens of thousands of > dollars that would have been > wasted on a piece of hardware that could never be made to > work correctly as designed. He > traced the read circuitry while I traced the write > circuitry and we then looked at each > other and said "this will never work!" and then spent > another four hours showing that not > only could software put it into this unusable state, but > once in it, the state could not > be detected or reset. > > I knew how VAX caches worked, and DECSystem-20 caches > worked. > > I was the Master of the JSYS on DECSystem-20. > > You don't succeed in this business without being a walking > encyclopedia of trivia. Big > pictures don't matter if you can't make them work on real > systems. > joe > **** >> >>I really can't stand debugging my own code, that is why I >>take very extreme measures to prevent bugs from occurring >>in >>the first place. I carefully design every single line of >>code, and check the design many times before I even try to >>compile it. Most of the code that I write mostly works the >>first time with only the most trivial logic errors. >> > **** > But it only works up to your design limits. The recent > discussion of multithreading shows > that the if the elegant design fails to account for > reality, it isn't a very good design. It showed that the optimal design worked better than anticipated. It turned out that it was the Microsoft Code generated the glyphs that would not multi-thread. I forgot that the MS code was taking most of the execution time. The test proved that my code would multi-thread. > Real designs have to be flexible. Historically, the only > other person I ever knew that > said this wrote code that worked the first time; but he > was months late on delivery > because while the rest of us were debugging real code that > mostly worked, he was still > thinking about his code. And it was horrendously slow; > when I measured it, and pointed > out the problems, he told me not a line could be changed > because all the decisions were > interacting and comitted, and on one line could not be > changed without disrupting the > entire application. We call that "fragile code". In > robust code, you can replug entire My code is not fragile it is optimized for speed. Now with the redesign space is minimized within optimal speed. > modules without anyone noticing the change. So we were > stuck with the horrible > performance, because the code was so complex no one else > could understand it. But he > never did any debugging on the machine; it was all desk > debugging. > joe > The other thing that I optimize besides time and space is complexity. My highest priority is to write elegant code that has nearly zero (Fred Brooks) accidental complexity. Everything about the code from the minimally coupled association between classes to the naming conventions makes the code as simple as possible. I also eliminate most every trace of any redundancy. I learned this from an email from Ward Cunningham the inventor of CRC cards. I asked him if he could only choose a single criterion measure of code quality what would it be. He said code size, eliminate redundant code. > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Hector Santos on 24 Mar 2010 19:09 Geoff wrote: > > Two bugs exist. > > 1. You never initialize num, so executing num = Data[num] will access > a garbage address in debug mode and will attempt to read Data[0] in > release mode since the OS will zero-fill num for you. Hmmmmmm, Geoff, since when did Windows load low? What version of Windows? Is it chip related? The only variables initializes as zero are objects. Otherwise all nature types in C are not initialized and need to be programmatically initialize. So unless there is something new in Windows Vista/7 I am not aware of. If so, this would be new to me. If so, I don't know if this would be good or bad since it can hide or mask a more serious programming bug, but I can understand Microsoft making the security decision today to load low process memory when it starts. Probably a safe choice overall, but I still think it would perpetuate by programming like the way Peter did there, probably assuming that Windows does indeed always starts memory at zero loaded. -- HLS
From: Hector Santos on 24 Mar 2010 19:26 Peter Olcott wrote: > I learned this from an email from Ward Cunningham the > inventor of CRC cards. I asked him if he could only choose a > single criterion measure of code quality what would it be. > He said code size, eliminate redundant code. He probably meant about reusability Peter. In programming, you can code for size or speed. redundant code is faster because you reduce stack overhead. When you code for size, you are reusing code which has stack overhead. But in the today's world of super fast machines and bloated windows, higher dependency on dlls, proxies and p-code RTL, and high code generated sizes, the code vs speed ideas is, IMO, a thing of the past. Cases in point: 1) .NET, reusability, higher stack overhead, but faster machines makes it all feasible. 2) The evolution of templates. Once a code for speed with the expense of redundant code and bigger size, today, it is doesn't really matter and is more virtualize with functional coding and interfacing. You do want speed, don't get me wrong, but you are not going to waste type not creating reusable code. One thing you can do quickly with functions is to use the inline statement. This is good for low overhead black box functions: inline const DWORD &GetRandom(const DWORD &size) { return (rand()*rand())%size; } This gives the smaller functional programming sizing,yet some speed considerations with reduce stack overhead. -- HLS
From: Malachy Moses on 24 Mar 2010 19:32
On Mar 24, 1:39 pm, "Peter Olcott" <NoS...(a)OCR4Screen.com> wrote: > > Here is an interesting note that I don't understand. A > slight revision (to make it a little less CPU intensive, > thus more memory intensive) only actually achieves 21 MB per > second of the 12 GB / second maximum RAM speed. (RAM speed > reported by MemTest86). > > const uint32 size = 100000000; > std::vector<uint32> Data; > uint32 Max = 0x3fffffff; > > void Process() { > clock_t finish; > clock_t start = clock(); > double duration; > uint32 num; > for (uint32 N = 0; N < Max; N++) > num = Data[num]; > finish = clock(); > duration = (double)(finish - start) / CLOCKS_PER_SEC; > printf("%4.2f Seconds\n", duration); > } > > Another thing that I don't understand is that it crashes > when > num = Data[num]; > is replaced by > num = Data[N]; I suppose that this is an example of code you wrote that "mostly works the first time with only the most trivial logic errors", as gloatingly boasted by you in your post over here: http://groups.google.com/group/microsoft.public.vc.mfc/tree/browse_frm/thread/c84953c13066a4f3/4b4e98102ea69979?rnum=11&_done=%2Fgroup%2Fmicrosoft..public.vc.mfc%2Fbrowse_frm%2Fthread%2Fc84953c13066a4f3%3F#doc_dd77f6384b369bb2 Quote from your post: "I really can't stand debugging my own code, that is why I take very extreme measures to prevent bugs from occurring in the first place. I carefully design every single line of code, and check the design many times before I even try to compile it. Most of the code that I write mostly works the first time with only the most trivial logic errors. " Really. Such modesty. I can see two errors immediately in only 14 lines of code, for an error rate of 14.3%. I apologize for the ad hominem attack. Although it's unlike me, I am compelled by the vast quantities of fine resources (from the likes of Joe and Hector) that are being wasted on this stuff. |