How hard is socket programming?
in [MFC]
|
Prev: Runtime Error does not specify program???
Next: windows 7 - imitating touch by sending wm_gesture ?
From: Peter Olcott on 18 Mar 2010 18:41 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:kl75q5pr3846rc6m4iiqad958ccoanrlba(a)4ax.com... > See below... > On Thu, 18 Mar 2010 10:59:43 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: > >> >>"Stephen Myers" >><""StephenMyers\"@discussions(a)microsoft.com"> wrote in >>message news:O7Fz2UqxKHA.6140(a)TK2MSFTNGP05.phx.gbl... >>> Peter Olcott wrote: >>>> "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >>>> message >>>> news:43b2q51hukg9s1gofoqds7vodf0lcq4bhp(a)4ax.com... >>>>> See below... >>>>> On Tue, 16 Mar 2010 22:19:25 -0500, "Peter Olcott" >>>>> <NoSpam(a)OCR4Screen.com> wrote: >>>>> >>>>>> "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >>>>>> message >>>>>> news:6ng0q5pbktq73efm697rl1tf18jv6dhknn(a)4ax.com... >>>>>>> On Tue, 16 Mar 2010 20:16:44 -0500, "Peter Olcott" >>>>>>> <NoSpam(a)OCR4Screen.com> wrote: >>>>>>> >>>>>>>> "Hector Santos" <sant9442(a)nospam.gmail.com> wrote >>>>>>>> in >>>>>>>> message >>>>>>>> news:ueIgi6WxKHA.1692(a)TK2MSFTNGP04.phx.gbl... >>>>>>>>> Peter Olcott wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> Fastest speed is highest priority, secondary to >>>>>>>>>> this is >>>>>>>>>> portability, it looks like FastCGI provides both. >>>>>>>>>> Another very high priority is minimal development >>>>>>>>>> costs. >>>>>>>>>> As far as I can tell FastCGI is good here too. >>>>>>>>> Dude, FastCGI is not a "Language." Its an idea, a >>>>>>>>> methodology that was designed with EARLY needs to >>>>>>>>> speed >>>>>>>>> up >>>>>>>>> loading time. You won't have that problem today. >>>>>>>> You continue to ignore my repeatedly stated >>>>>>>> requirement of >>>>>>>> 4.0 GB of data (a deterministic finite automaton) >>>>>>>> that >>>>>>>> must >>>>>>>> be loaded before execution can begin. If you ignore >>>>>>>> my >>>>>>>> fundamental requirements you can't possibly provide >>>>>>>> good >>>>>>>> advice. >>>>>>> *** >>>>>>> And you continue to ignore our observations that >>>>>>> there >>>>>>> are >>>>>>> no technologies that guarantee >>>>>>> this, and the timings of program behavior can be >>>>>>> swamped >>>>>>> by communication times (did I >>>>>>> tell you about the 70-second DNS resolution time? >>>>>>> Did >>>>>>> you >>>>>>> know that you can expect delays >>>>>>> in integer number of seconds to locate your server?) >>>>>>> >>>>>> That is horrendous. I doubt if it is frequent, and >>>>>> local >>>>>> caching would hopefully prevent it from recurring. >>>>> **** >>>>> Depends. Did the end user configure for local DNS >>>>> caching? WHat was the cache retention >>>>> time set by the end user? Note, again, YOU HAVE NO >>>>> CONTROL OVER THESE PARAMETERS! >>>>> **** >>>>>>> You fasten on some technology that says it is >>>>>>> "faster" >>>>>>> and >>>>>>> assume it is the answer to your >>>>>>> problem; you toss jargon around in ways that those >>>>>>> of >>>>>>> us >>>>>>> who know the technology don't >>>>>>> even recognize, such as assertions how FastCGI >>>>>>> allows >>>>>>> you >>>>>>> to have browse buttons in the >>>>>> It seems to me that most of you guys continue to >>>>>> simply >>>>>> ignore some of my most fundamental design >>>>>> requirements. >>>>>> App >>>>>> load time for me can be several minutes, app >>>>>> execution >>>>>> time >>>>>> of a large job is never more than 100 milliseconds. >>>>> ***** >>>>> No, we hear them, we just don't believe that FastCGI >>>>> is >>>>> going to be the solution that will >>>>> solve every issue for you. Hector says that CGI has >>>>> been improved to where it has >>>>> comparable performance to FastCGI. I have no >>>>> information to confirm or deny that >>>>> statement. Again, you are not a server expert, so you >>>>> should pay attention to the server >>>>> expert. >>>>> **** >>>>>> If the app is the only process besides the OS, by >>>>>> limiting >>>>>> memory usage to no more than 75% of available RAM in >>>>>> actual >>>>>> practice both the app and its data are paged out >>>>>> almost >>>>>> not >>>>>> at all. On a real-time OS this behavior would be >>>>>> guaranteed. >>>>>> On MS Windows it is close enough. Linux probably does >>>>>> not do >>>>>> worse than Windows in this regard. >>>>> **** >>>>> I have no idea why you think this is true. This is >>>>> not >>>>> an assumption I would have >>>>> considered valid until I talked to a linux expert >>>>> (since >>>>> you will be hosted on linux). Yet >>>>> you make this assertion simply because you THINK it >>>>> should work, as opposed to getting >>>>> data that confirms that the OS actually works this >>>>> way. >>>>> **** >>>> >>>> An OS that unloads any part of an executing process >>>> when >>>> it has no need for additional memory would be an >>>> idiotic >>>> OS. It would be flat out stupid to do this. I am not >>>> convinced that either Windows or Linux is this stupid. >>>> >>>> If this same OS unloads part of a process because the >>>> process has been idle for a long time, AND needs more >>>> memory to do some housekeeping task, then this case I >>>> could see a reason that would not be stupid. >>>> >>> Why should any OS keep all of your process in memory at >>> all? The concept of paged virtual memory allows the OS >>> to >>> keep what's currently needed in memory. This allows 10 >>> or >>> 20 or 500 processes to have the illusion that their 2GB >>> is >>> resident whenever they're running. Consider a program >>> that puts up a logo from a resource at startup. Should >>> the OS keep that snippet (page) of memory in physical >>> memory on the off chance that it will be needed again? >> >>In my particular instance the dedicated server will only >>have the single purpose of running my OCR web application. >>If I have to I will turn virtual memory off. It must keep >>my >>process in memory even if I have to make changes to the OS >>to achieve this. The simplest way that I can force the >>data >>to remain resident, is to access every memory location >>whenever my process is otherwise idle. > **** > And you know linux support this? If Linux has threads, then it must support this. If it does not have threads then IPC from another process would support this. > > And you know the host company will make the necessary > configuration changes? > joe Its only a tedious detail. I can always do the whole thing myself (buy my own connection to the web) as a last resort, its not really all that difficult. I am betting that the half hour test will pass. > **** >> >>> >>>>>>> local Web server, and how it is the perfect answer >>>>>>> to >>>>>>> all >>>>>>> your problems, when we know it >>>>>>> isn't anything but another hack whose purpose is to >>>>>>> compensate for bad initiali designs >>>>>>> (CGI requiring a new process per request). You >>>>>>> ignore >>>>>>> core issues such as how you are >>>>>>> going to port your app so it runs on a linux or Unix >>>>>>> server, and how you are going to >>>>>> I am rewriting it to require very little OS specific >>>>>> code. >>>>>> About the only thing that I will have to change is >>>>>> the >>>>>> way >>>>>> that PNG files are read into memory. I will have to >>>>>> switch >>>>>> to LibPNG. All of the MFC code is only development >>>>>> code >>>>>> and >>>>>> will not be part of production. >>>>> **** >>>>> PNG files would not be "read into memory"; instead, >>>>> you >>>>> will need to convert the input >>>>> string (however it is provided, most likely via stdin) >>>>> to a bitmap, and that requires a >>>>> library that does not read the PNG data from a file >>>>> but >>>>> from a text stream. >>>>> **** >>>> >>>> YES, or if I have to write is to disk and read it back >>>> in >>>> again. Reading and writing 2K files will not kill me. >>>> >>>>>>> rewrite it to be platform-independent and possibly >>>>>>> even >>>>>>> GUI-free, and your unrealistic >>>>>> The web service needs no GUI. It is all PNG in, and >>>>>> UTF-8 >>>>>> out. >>>>> **** >>>>> OK, that's good. You *will* have to write the FastCGI >>>>> interface and make sure it works >>>>> multithreaded so it can handle multiple requests. >>>> >>>> I am going with Hectors idea of a tiny embedded >>>> webserver >>>> built in to my code. There are several freeware one's >>>> one of these looks good enogh for my needs: mongoose. >>>> >>>>> **** >>>>>>> expectations about how process memory is managed, >>>>>>> and >>>>>>> how >>>>>>> every OS is magically going to >>>>>>> behave in the way you wish, without any effort on >>>>>>> your >>>>>>> part. ANd you refuse to listen >>>>>>> when people tell you that you don't understand >>>>>>> either >>>>>>> the >>>>>>> technology or the intrinsic >>>>>>> behavior of how an operating system works. >>>>>>> >>>>>>> You really need to do better research on these >>>>>>> technologies before you start making such >>>>>>> assertions, or ask questions and pay attention to >>>>>>> the >>>>>>> answers. I'm not even a Web server >>>>>>> expert like Hector, and I can tell you are making >>>>>>> nonsensical statements. Listen to him. >>>>>>> He sounds like someone who does this for a living, >>>>>>> and >>>>>>> you >>>>>>> should trust what he is telling >>>>>>> you. >>>>>>> joe >>>>>> All that I know for sure is that some of my >>>>>> fundamental >>>>>> requirements are immutable. Some of Hector's advice >>>>>> seemed >>>>>> to continue to ignore these requirements. I was >>>>>> envisioning >>>>>> the web service as a single application. This may not >>>>>> have >>>>>> been the way that he was envisioning it. >>>>> **** >>>>> You can do it by writing a "front end" that exports a >>>>> known port and implements your >>>>> appliction-specific protocol to get the data to send >>>>> to >>>>> your "business logic" component. >>>>> It doesn't solve the paging problem, or the 4GB >>>>> problem. >>>>> joe >>>> >>>> I think that I will be going with some sort of >>>> application specific webserver such as mongoose. Hector >>>> tried to sell me on his webserver, but, it was too >>>> costly >>>> and not flexible enough for me right now. In the future >>>> when I scale up to multiple servers this may change. >>>> >>>>> **** >>>>>>>>> Its nonsense to think this is "answer" to >>>>>>>>> your problem. In addition, if you worry about >>>>>>>>> processing >>>>>>>>> speed, native C/C++ is your choice, so all you are >>>>>>>>> doing >>>>>>>>> is writing a CGI application, a console >>>>>>>>> application >>>>>>>>> that >>>>>>>>> reads standard input. >>>>>>>>> >>>>>>>>> If you want productivity, learn PHP. Simple, well >>>>>>>>> supported. Then if you really find out that >>>>>>>>> FASTCGI >>>>>>>>> is >>>>>>>>> needed for your slow OS and machine, PHP supports >>>>>>>>> it. >>>>>>>>> >>>>>>>>> The point is your SOLUTION is not FASTCGI, it is >>>>>>>>> the >>>>>>>>> actual application that does the work. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> HLS >>>>>>> Joseph M. Newcomer [MVP] >>>>>>> email: newcomer(a)flounder.com >>>>>>> Web: http://www.flounder.com >>>>>>> MVP Tips: http://www.flounder.com/mvp_tips.htm >>>>> Joseph M. Newcomer [MVP] >>>>> email: newcomer(a)flounder.com >>>>> Web: http://www.flounder.com >>>>> MVP Tips: http://www.flounder.com/mvp_tips.htm >>>> > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Peter Olcott on 18 Mar 2010 18:44 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:vn75q5dpobop8jk9r1qllphrm4a2p36mpn(a)4ax.com... > See below... > On Thu, 18 Mar 2010 11:12:36 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: > >> >>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >>message news:f9h4q5ltbdi70eot2n5me08gij5vg556bc(a)4ax.com... >>> See below... >>> On Wed, 17 Mar 2010 15:04:40 -0500, "Peter Olcott" >>> <NoSpam(a)OCR4Screen.com> wrote: >>> >>>> >>>>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >>>>message >>>>news:43b2q51hukg9s1gofoqds7vodf0lcq4bhp(a)4ax.com... >>>>> See below... >>>>> On Tue, 16 Mar 2010 22:19:25 -0500, "Peter Olcott" >>>>> <NoSpam(a)OCR4Screen.com> wrote: >>>>> >>>>>> >>>>>>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >>>>>>message >>>>>>news:6ng0q5pbktq73efm697rl1tf18jv6dhknn(a)4ax.com... >>>>>>> On Tue, 16 Mar 2010 20:16:44 -0500, "Peter Olcott" >>>>>>> <NoSpam(a)OCR4Screen.com> wrote: >>>>>>> >>>>>>>> >>>>>>>>"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in >>>>>>>>message >>>>>>>>news:ueIgi6WxKHA.1692(a)TK2MSFTNGP04.phx.gbl... >>>>>>>>> Peter Olcott wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> Fastest speed is highest priority, secondary to >>>>>>>>>> this >>>>>>>>>> is >>>>>>>>>> portability, it looks like FastCGI provides both. >>>>>>>>>> Another very high priority is minimal development >>>>>>>>>> costs. >>>>>>>>>> As far as I can tell FastCGI is good here too. >>>>>>>>> >>>>>>>>> Dude, FastCGI is not a "Language." Its an idea, a >>>>>>>>> methodology that was designed with EARLY needs to >>>>>>>>> speed >>>>>>>>> up >>>>>>>>> loading time. You won't have that problem today. >>>>>>>> >>>>>>>>You continue to ignore my repeatedly stated >>>>>>>>requirement >>>>>>>>of >>>>>>>>4.0 GB of data (a deterministic finite automaton) >>>>>>>>that >>>>>>>>must >>>>>>>>be loaded before execution can begin. If you ignore >>>>>>>>my >>>>>>>>fundamental requirements you can't possibly provide >>>>>>>>good >>>>>>>>advice. >>>>>>> *** >>>>>>> And you continue to ignore our observations that >>>>>>> there >>>>>>> are >>>>>>> no technologies that guarantee >>>>>>> this, and the timings of program behavior can be >>>>>>> swamped >>>>>>> by communication times (did I >>>>>>> tell you about the 70-second DNS resolution time? >>>>>>> Did >>>>>>> you >>>>>>> know that you can expect delays >>>>>>> in integer number of seconds to locate your server?) >>>>>>> >>>>>> >>>>>>That is horrendous. I doubt if it is frequent, and >>>>>>local >>>>>>caching would hopefully prevent it from recurring. >>>>> **** >>>>> Depends. Did the end user configure for local DNS >>>>> caching? WHat was the cache retention >>>>> time set by the end user? Note, again, YOU HAVE NO >>>>> CONTROL OVER THESE PARAMETERS! >>>>> **** >>>>>> >>>>>>> You fasten on some technology that says it is >>>>>>> "faster" >>>>>>> and >>>>>>> assume it is the answer to your >>>>>>> problem; you toss jargon around in ways that those >>>>>>> of >>>>>>> us >>>>>>> who know the technology don't >>>>>>> even recognize, such as assertions how FastCGI >>>>>>> allows >>>>>>> you >>>>>>> to have browse buttons in the >>>>>> >>>>>>It seems to me that most of you guys continue to >>>>>>simply >>>>>>ignore some of my most fundamental design >>>>>>requirements. >>>>>>App >>>>>>load time for me can be several minutes, app execution >>>>>>time >>>>>>of a large job is never more than 100 milliseconds. >>>>> ***** >>>>> No, we hear them, we just don't believe that FastCGI >>>>> is >>>>> going to be the solution that will >>>>> solve every issue for you. Hector says that CGI has >>>>> been >>>>> improved to where it has >>>>> comparable performance to FastCGI. I have no >>>>> information >>>>> to confirm or deny that >>>>> statement. Again, you are not a server expert, so you >>>>> should pay attention to the server >>>>> expert. >>>>> **** >>>>>> >>>>>>If the app is the only process besides the OS, by >>>>>>limiting >>>>>>memory usage to no more than 75% of available RAM in >>>>>>actual >>>>>>practice both the app and its data are paged out >>>>>>almost >>>>>>not >>>>>>at all. On a real-time OS this behavior would be >>>>>>guaranteed. >>>>>>On MS Windows it is close enough. Linux probably does >>>>>>not >>>>>>do >>>>>>worse than Windows in this regard. >>>>> **** >>>>> I have no idea why you think this is true. This is >>>>> not >>>>> an >>>>> assumption I would have >>>>> considered valid until I talked to a linux expert >>>>> (since >>>>> you will be hosted on linux). Yet >>>>> you make this assertion simply because you THINK it >>>>> should >>>>> work, as opposed to getting >>>>> data that confirms that the OS actually works this >>>>> way. >>>>> **** >>>> >>>>An OS that unloads any part of an executing process when >>>>it >>>>has no need for additional memory would be an idiotic >>>>OS. >>>>It >>>>would be flat out stupid to do this. I am not convinced >>>>that >>>>either Windows or Linux is this stupid. >>> *** >>> But we learned DECADES ago that "eager page-out" >>> improves >>> overall system performance, >>> because it reduces startup transients when a process (or >>> one of its threads) becomes >>> schedulable. Again, the "working set" has to be paged >>> in, >>> and this is easier if there are >>> available page frames in memory. So what you are >>> calling >>> "stupid" is in fact the >>> DEMONSTRATED INTELLIGENT way to build operating systems, >>> and we've known this since they >>> early 1970s. This is why I have never known a system >>> that >>> did not page out an idle >>> process IN ANITICIPATION OF NEED. Windows does it; I'm >>> trying to find out if linux does >>> it, but again, your opinion of how you THINK an >>> operating >>> system SHOULD work flies in the >>> fact of reality. Just because you don't see a reason >>> doesn't mean there isn't one, and >>> one that has been established by long practice (the >>> "actual practice" you fantasize about >>> doesn't exist). Windows indeed works this way, and so >>> have other operating systems, all >>> based on BEST practice (not someone's fantasized "actual >>> practice"). So I would not >>> predicate actual behavior on fantasies, but learn the >>> facts. >>> ***** >> >>I will simply do whatever it takes to achieve the >>functional >>result that I require. If there is always an extra 4.0 GB >>of >>RAM available, then your whole anticipation of need >>concept >>should become moot. >> > **** > Maybe. You are still basing this on wishful thinking of > what you think OUGHT to happen, > rather than finding out what the real operating system > does.... > joe If it does not work this way, I will find one way or another to make it work this way. I have never seen it not work this way in my 26 years of professional experience. > > **** >>>> >>>>If this same OS unloads part of a process because the >>>>process has been idle for a long time, AND needs more >>>>memory >>>>to do some housekeeping task, then this case I could see >>>>a >>>>reason that would not be stupid. >>> **** >>> It is the antiipation-of-need which in actual practice >>> (not fantasized "actual practive", >>> but ACTUAL practice) has been found to be the best >>> solution for general purpose operating >>> systems, to maximize overall performance. Until you >>> have >>> measured (there's that nasty >>> phrase, implying the obtaining of facts) behavior, you >>> have no reason to assume it >>> corresponds to your fantasies. >>> **** >>>> >>>>>> >>>>>>> local Web server, and how it is the perfect answer >>>>>>> to >>>>>>> all >>>>>>> your problems, when we know it >>>>>>> isn't anything but another hack whose purpose is to >>>>>>> compensate for bad initiali designs >>>>>>> (CGI requiring a new process per request). You >>>>>>> ignore >>>>>>> core issues such as how you are >>>>>>> going to port your app so it runs on a linux or Unix >>>>>>> server, and how you are going to >>>>>> >>>>>>I am rewriting it to require very little OS specific >>>>>>code. >>>>>>About the only thing that I will have to change is the >>>>>>way >>>>>>that PNG files are read into memory. I will have to >>>>>>switch >>>>>>to LibPNG. All of the MFC code is only development >>>>>>code >>>>>>and >>>>>>will not be part of production. >>>>> **** >>>>> PNG files would not be "read into memory"; instead, >>>>> you >>>>> will need to convert the input >>>>> string (however it is provided, most likely via stdin) >>>>> to >>>>> a bitmap, and that requires a >>>>> library that does not read the PNG data from a file >>>>> but >>>>> from a text stream. >>>>> **** >>>> >>>>YES, or if I have to write is to disk and read it back >>>>in >>>>again. Reading and writing 2K files will not kill me. >>>> >>>>>> >>>>>>> rewrite it to be platform-independent and possibly >>>>>>> even >>>>>>> GUI-free, and your unrealistic >>>>>> >>>>>>The web service needs no GUI. It is all PNG in, and >>>>>>UTF-8 >>>>>>out. >>>>> **** >>>>> OK, that's good. You *will* have to write the FastCGI >>>>> interface and make sure it works >>>>> multithreaded so it can handle multiple requests. >>>> >>>>I am going with Hectors idea of a tiny embedded >>>>webserver >>>>built in to my code. There are several freeware one's >>>>one >>>>of these looks good enogh for my needs: mongoose. >>>> >>>>> **** >>>>>> >>>>>>> expectations about how process memory is managed, >>>>>>> and >>>>>>> how >>>>>>> every OS is magically going to >>>>>>> behave in the way you wish, without any effort on >>>>>>> your >>>>>>> part. ANd you refuse to listen >>>>>>> when people tell you that you don't understand >>>>>>> either >>>>>>> the >>>>>>> technology or the intrinsic >>>>>>> behavior of how an operating system works. >>>>>>> >>>>>>> You really need to do better research on these >>>>>>> technologies before you start making such >>>>>>> assertions, or ask questions and pay attention to >>>>>>> the >>>>>>> answers. I'm not even a Web server >>>>>>> expert like Hector, and I can tell you are making >>>>>>> nonsensical statements. Listen to him. >>>>>>> He sounds like someone who does this for a living, >>>>>>> and >>>>>>> you >>>>>>> should trust what he is telling >>>>>>> you. >>>>>>> joe >>>>>> >>>>>>All that I know for sure is that some of my >>>>>>fundamental >>>>>>requirements are immutable. Some of Hector's advice >>>>>>seemed >>>>>>to continue to ignore these requirements. I was >>>>>>envisioning >>>>>>the web service as a single application. This may not >>>>>>have >>>>>>been the way that he was envisioning it. >>>>> **** >>>>> You can do it by writing a "front end" that exports a >>>>> known port and implements your >>>>> appliction-specific protocol to get the data to send >>>>> to >>>>> your "business logic" component. >>>>> It doesn't solve the paging problem, or the 4GB >>>>> problem. >>>>> joe >>>> >>>>I think that I will be going with some sort of >>>>application >>>>specific webserver such as mongoose. Hector tried to >>>>sell >>>>me >>>>on his webserver, but, it was too costly and not >>>>flexible >>>>enough for me right now. In the future when I scale up >>>>to >>>>multiple servers this may change. >>>> >>>>> >>>>> **** >>>>>> >>>>>>> >>>>>>>> >>>>>>>> > Its nonsense to think this is "answer" to >>>>>>>>> your problem. In addition, if you worry about >>>>>>>>> processing >>>>>>>>> speed, native C/C++ is your choice, so all you are >>>>>>>>> doing >>>>>>>>> is writing a CGI application, a console >>>>>>>>> application >>>>>>>>> that >>>>>>>>> reads standard input. >>>>>>>>> >>>>>>>>> If you want productivity, learn PHP. Simple, well >>>>>>>>> supported. Then if you really find out that >>>>>>>>> FASTCGI >>>>>>>>> is >>>>>>>>> needed for your slow OS and machine, PHP supports >>>>>>>>> it. >>>>>>>>> >>>>>>>>> The point is your SOLUTION is not FASTCGI, it is >>>>>>>>> the >>>>>>>>> actual application that does the work. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> HLS >>>>>>>> >>>>>>> Joseph M. Newcomer [MVP] >>>>>>> email: newcomer(a)flounder.com >>>>>>> Web: http://www.flounder.com >>>>>>> MVP Tips: http://www.flounder.com/mvp_tips.htm >>>>>> >>>>> Joseph M. Newcomer [MVP] >>>>> email: newcomer(a)flounder.com >>>>> Web: http://www.flounder.com >>>>> MVP Tips: http://www.flounder.com/mvp_tips.htm >>>> >>> Joseph M. Newcomer [MVP] >>> email: newcomer(a)flounder.com >>> Web: http://www.flounder.com >>> MVP Tips: http://www.flounder.com/mvp_tips.htm >> > 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 18 Mar 2010 19:08 On Mar 18, 6:47 pm, "Peter Olcott" <NoS...(a)OCR4Screen.com> wrote: > I still have every email message that I have ever received > (including attachments) in the last six years and they are > taking up 2% of my 1 GB allocated server space. Yeah, and your input is about 0.023% of the new storage of quoted wasted bandwidth. I just did a download of your last 3 post you made and let me count..... - 3 messages - 1087 lines - 26 lines of new input by you Thats 0.023% or 99.98% waste of communications bandwidth and wasted CPU power required by hundreds of thousands, if not millions of news gate systems and readers. Hey, I personally don't care if top posting or inline quoting is used, it is over quoting of all the non-relevant text that makes all hard to read and not truncating the remainder of the quote is well, very odd.
From: Geoff on 18 Mar 2010 20:30 On Thu, 18 Mar 2010 11:32:55 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: >Yes and it also looks like converting to 64-bit will cost >very little system resources. I was thinking that >std::vector elements would increase in size by four bytes. >With further consideration this would seem to not be the >case. The STL was written for 32 bits. Unless there has been a change to the standard to accommodate 64 bits you will be limited. In any case, for now it is implementation dependent. Beware vector.max_size(), it returns a 32 bit value but on Win32 it's impossible to use vectors up to max_size() for lack of memory capacity. The STL implementation has no knowledge about the OS limitations. A Win32 app running in Win64 might be able to make full use of max_size() but you will need to test it. The templates fail in exactly the same way on Linux32 platforms with all the GCC implementations I have tested.
From: Peter Olcott on 18 Mar 2010 21:28
"Geoff" <geoff(a)invalid.invalid> wrote in message news:nvg5q59n1229l8k3baqtq7r77pk59q59f6(a)4ax.com... > On Thu, 18 Mar 2010 11:32:55 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: > >>Yes and it also looks like converting to 64-bit will cost >>very little system resources. I was thinking that >>std::vector elements would increase in size by four bytes. >>With further consideration this would seem to not be the >>case. > > The STL was written for 32 bits. Unless there has been a > change to the > standard to accommodate 64 bits you will be limited. In > any case, for > now it is implementation dependent. > > Beware vector.max_size(), it returns a 32 bit value but on > Win32 it's > impossible to use vectors up to max_size() for lack of > memory > capacity. The STL implementation has no knowledge about > the OS > limitations. A Win32 app running in Win64 might be able to > make full > use of max_size() but you will need to test it. The > templates fail in > exactly the same way on Linux32 platforms with all the GCC > implementations I have tested. No problem I have already written std::vector from scratch once, so I could do it again. The platform specific aspect would be limited by whatever malloc() could handle. "new" is probably implemented using malloc(). I wanted to have a std::vector on my Borland Turbo C++ 1.01 to run on my handheld HP 200LX. The std::vector stuff was pretty easy, the hard part was implementing a generic std::vector without the use of templates. I wrote the std::vector after I beat out the vendor's (Borland C++ Builder 4.0 and Microsoft VC++ 6.0) implementation of std::string by about 50-fold increase in speed. |