TextOut() to a DialogBox ???
in [MFC]
|
From: Peter Olcott on 29 Mar 2010 14:57 "Liviu" <lab2k1(a)gmail.c0m> wrote in message news:eQk%23NMwzKHA.5348(a)TK2MSFTNGP02.phx.gbl... > "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote... >> "JustBoo" <Boo(a)boowho.com> wrote... >>> On 3/23/2010 9:09 PM, Peter Olcott wrote: >>>> Personally I really hate dealing with tedious little >>>> details, [...] >>>> 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. >>> >>> Ding! Check Please! [...] >> >> Just because a statement may be unbelievable does not >> logically >> entail that this statement is not a verifiable fact, time >> will tell. > > Just curious, but how long a time would one expect before > it "tells"? > I am estimating that the worst case is at about a year from now.
From: Hector Santos on 29 Mar 2010 15:58 Peter Olcott wrote: >> Just curious, but how long a time would one expect before >> it "tells"? >> > > I am estimating that the worst case is at about a year from > now. That isn't the worst case, but the best case. The worst case is 10 years from now or never getting it done. Here is the thing, I and most people experience with client/server designs, and just open-minded developers who know how to solve the problem can get this done in 1 day or less ready for beta testing. All you need to do is follow BCP (Best Current Practice) methodologies that was provided to you. -- HLS
From: Liviu on 29 Mar 2010 16:14 "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote... > "Liviu" <lab2k1(a)gmail.c0m> wrote... >> >> Looking at the recent "memory read speed test" code you posted in >> this thread, and referring strictly to the "most trivial logic >> errors" (not the deeper confusion of what you were trying to measure >> and match) but... it took two painfully obvious corrections before >> the thing even ran. > > Factually incorrect, It ran before I posted it and I posted it from > cut-and-paste. This new claim of yours is factually (and laughably) incorrect. The code you first posted in this thread at http://groups.google.com/group/microsoft.public.vc.mfc/msg/cdb1eb4574518d7e?hl=en&dmode=source was incomplete to begin with, had only an empty std::vector in sight, and clearly had an unitialized 'uint32 num' being used. Both of those were "painfully obvious" errors, quickly pointed out in the replies. Yet, you are trying to say now, with a straight face, that the code ran as posted. Amazing. Wishful thinking, much? Then, the second revision of your code posted in this thread at http://groups.google.com/group/microsoft.public.vc.mfc/msg/cf54aeb717b24ad8?hl=en&dmode=source started with the question "Why does the code below crash?". >> Then, you had a couple more naivetes which just happened to >> cancel out, writing a loop with no side effects, but forgetting to >> "#define _SECURE_SCL 0" so that the loop wasn't optimized away >> altogether (but then contained std::vector bounds checking code which >> did not belong in a "raw speed' test). Later, there was at least one >> other correction from another group where you posted a followup, >> about that odd rand()*rand() idea. >> >> And the above doesn't even begin to nitpick on "boring details" such >> as whether you think that your latest "GetRandom" really returns a >> random uint32 (hint: no, just the lower 30 bits are random), or that > > Sufficient for its intended purpose. It was modeling a process with > widely dispersed memory access patterns, not random access patterns, > thus the lack of true randomness misses the point. You miss the point, again. The latest "GetRandom" happens to work with just the lower 30 bits random, because you are accessing 32b aligned addresses, so there is an implicit multiply-by-4 on the byte offset. That's a left-shift by 2 bits and 30+2=32, in case it's not obvious, so you end up with a random 32b aligned address across the entire 32b addressable space. Call that dumb luck (in this particular case) but don't rely on it for always working on your side. > The quick and dirty program provided the response time curves related > to size of memory allocation sufficiently for its intended purpose. One can only guess what the "intended purpose" was, since your targets seem to ever change. But I notice you mentioned "locality of reference" in another post today. At least that's a step in the right direction. Liviu
From: Liviu on 29 Mar 2010 17:16 "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote... > "Liviu" <lab2k1(a)gmail.c0m> wrote... >> "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote... >>> "Liviu" <lab2k1(a)gmail.c0m> wrote... > >>> Sufficient for its intended purpose. It was modeling a process with >>> widely dispersed memory access patterns, not random access patterns, >>> thus the lack of true randomness misses the point. >> >> You miss the point, again. The latest "GetRandom" happens to work >> with just the lower 30 bits random, because you are accessing 32b >> aligned [addresses, so there is an implicit multiply-by-4] > > I don't miss the point YOU miss the point. It does not have to be > random at all, so all of your criticisms that it is not random enough > utterly miss the point. Oh, for Pete's sake! You _continue_ to miss the point. I noted that your latest GetRandom (= (rand() * (RAND_MAX + 1) + rand()) % size) provided only 30 random bits. For some reason, you took that as an attack on the randomness (rather than the range), and defended that you didn't actually need "true randomness". Then I pointed that it _happened_ to work for the 32b-aligned addresses in your test case, which always have the lowest 2 bits set to 0. Now you repeat the "random enough" mantra, just to confirm that you had no clue that it _did_ in fact work, did so by chance, or why it happened to. Liviu
From: Hector Santos on 29 Mar 2010 22:00
Peter Olcott wrote: > The quick and dirty program provided the response time > curves related to size of memory allocation sufficiently for > its intended purpose. Run your test with this utility: http://technet.microsoft.com/en-us/sysinternals/dd535533.aspx And watch how fancy it will colorize your application pages and memory usage! -- HLS |