--------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00478 Date: 04/30/98 From: CAREY BLOODWORTH Time: 09:34pm \/To: GEORGE WHITE (Read 1 times) Subj: Bubble And Squeak Sortin GW>CB>When you are talking about dung, what difference does it make what GW>CB>animal it came from. It's still going to smell the same. GW>Quite a lot, quanitity for one thing :-) ... Well, I have to admit, I wouldn't want to clean up from an elephant with a poodle's pooper scooper! GW>CB>And, no, it's not a new family. GW>We'll have agree to disagree here. I think it is, and I don't think I'll GW>convince you to change you view. Nope. As long as you can trace the relationship / history, I really can't see how you or anyone else can call it a new algorithm, with a straight face. At best, you can only call it a variation. GW>CB>A _NEW_ family means it's not a simple, incredibly minor modification o GW>CB>another family. They may not be the exact same algorithm, but they are GW>CB>definitely related and in the same family. When you can make a change GW>CB>that minor, it doesn't instantly become a new algorithm. GW>But straight insertion and straight selection sort have identical loop GW>structures, does that make them the same? Can you trace their operation / existence _directly_ from another algorithm or each other? If you can, then they are related and you are dealing with variations. See my message to David Noon about applying biological classification techniques to algorithms. --- QScan/PCB v1.19b / 01-0162 * Origin: Jackalope Junction 501-785-5381 Ft Smith AR (1:3822/1) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00479 Date: 04/30/98 From: CAREY BLOODWORTH Time: 09:34pm \/To: ANTHONY TIBBS (Read 1 times) Subj: TV20 AT>AT>Is there a "easy to follow", "start from scratch" tutorial on Turbo Visio AT>AT>(v2.0) around? If the user's guide is anything like the OWL tutorial, AT>don'tAT>even mention it. AT> AM> Just to complain, the one that comes with BC++3.1 is much, AT> AM> much more worse (how many levels of worse are there?) then AT> AM> the OWL. It's really criptic. AT>That is what I was afraid of. The OWL "tutorial" is too confusing for me, AT>even though I am familiar with C/C++. They add all these things, but on't AT>tell you what they do. :-) Unfortunately, to a large degree, that's simply the nature of event driven programming. Where as normal procedural programming has bunches of functions, an event driven program makes signals out of the larger, more 'universal' stuff. Sort of like OOP except instead of classes, it uses events that you process with switch statements, and instead of calling base classes, you 'singal' base classes, and so on. --- QScan/PCB v1.19b / 01-0162 * Origin: Jackalope Junction 501-785-5381 Ft Smith AR (1:3822/1) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00480 Date: 04/30/98 From: CAREY BLOODWORTH Time: 09:34pm \/To: DARIN MCBRIDE (Read 1 times) Subj: FREE MEMORY SPACE CALC? DM> CB> I'm needing some suggestions on how to reasonably portable calculate th DM> CB> amount of free memory left. DM>OS/2: Use the API. Mind you, there's much more information than you need I'll save it and take a look at it. DM> CB> Rather than each place checking the pointer for success, it just uses a DM> CB> very simple minded wrapper that aborts the entire program if DM> CB> unsuccessful. That's not a very good strategy! DM>It probably is - how often does your code run out of memory? ;-) Actually, as I haven't actually done anything with it, never! And with a virtual memory system, (or even a few hundred K), it's not likely. D-Flat itself, probably uses, at worst, 64k. Even for a major session. About 300 bytes for each window, plus whatever memory to save that area of the text screen, plus memory for dialogs and such (perhaps extra 100 bytes for the dialog window structure), plus memory for strings and controls (such as text in a selection window, etc.). The online help system uses some for the index of the context sensitive help, but I think that's only a few K, since the text itself remains on disk until a specific section is needed. It's actually fairly meager usage. All of the allocations are small ones. I've seriously considered just allocating 64k or so and just letting D-Flat itself use that. (I chose against that because of the possibility of fragmentation.) Except for the editor. The problem is the way the editor is written. I need to rework it. That's the main thing that can fail. The text is kept in memory all at once (of course), and then when it needs to increase the buffer, it just uses realloc, and if it fails, the whole program aborts. I could just fix this (and I do need to rewrite parts of it), but even without it, the very fact that D-Flat can just fail and simply the exit the program is not a satisfactory action. Turbo Vision doesn't have this problem, but only because it doesn't resize the editor buffer. You set a fixed limit size when you initialize the editor, and then when it's full, there's nothing you can do about it. I could make D-Flat like that, but I like its ability to increase the size of the buffer as needed. DM> CB> The real problem, I guess, is the possibility of running out of emory DM> CB> abruptly, without giving the user fair warning. DM>"If this program aborts, get more memory, or try the DPMI version." Not everybody has that option. If I'm going to make it 'generic', then I need to make it really generic enough to handle most computers. --- QScan/PCB v1.19b / 01-0162 * Origin: Jackalope Junction 501-785-5381 Ft Smith AR (1:3822/1) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00481 Date: 04/30/98 From: CAREY BLOODWORTH Time: 09:34pm \/To: DARIN MCBRIDE (Read 1 times) Subj: FINDFIRST & FINDNEXT DM> CB> comparable functions if their OS provides it. It's just that a lot f DM> CB> OSs don't even provide comparable functions, so I felt I needed to give DM> CB> them some. DM>Hmmm... snippets... dirport.[ch]... ;-) Nope. Dirport only provides it on OSs that already have comparable funtions. it just deals with naming differences and so on. My goal in writing findfirst & findnext was to provide it on OSs that didn't have anything like it. As for using dirport for the OSs that do have comparable routines.... No offense to Bob, but I really don't like the way dirport (and a lot of other things in snippets) are done. I don't _use_ snippets as is. I don't even have snippets actually 'installed'. I leave it archived and browse when needed. I don't do a lot of portability stuff, like he does, but I prefer to rip out all the other stuff I'm not needing, and just use the core. To me, it just seems like every snippet file tries to be totally aware of every system and compiler. That seems to clutter things (just try and read dirport.h....) I prefer to offer a single interface and provide seperate headers for each version that needs it. To extend that to snippets situation, you'd end up with dozens of compiler specific headers. One for each compiler on each platform. And each header provides all the compatability wrappers / macros that the rest of snippets uses. And for every new platform or compiler that comes out, you'd need to provide one more header. For something like snippets, that wouldn't really be practical. For my D-Flat, it is. There are only a few areas that really need portability, and it shouldn't take much for a person to provide what his compiler/OS needs, and only that platform. Not even caring about other platforms. DM>Basically, the structures that the OS has are "global" and "numerous". That DM>is ... you can have multiple searches going on simultaneously. However, tha DM>means you have to tell the OS you're done so it can reuse the slot later. Well, the findnext does close the dir, by using closedir(). So, as soon as the search ends, the OS/2 directory gets closed. The only other OS functions that get used are stat() and the localtime, neither of which would need to be closed. And findfirst/next itself shouldn't care whether multiple searchs are going on or not, because all of their data comes from pointers you pass to it, or local stack data. In each case, that data would change when a thread changes, so those functions wouldn't notice. DM> CB> Are you saying that OS/2 has findfirst/findnext, and it also has a DM> CB> findclose function? And that I need to provide a 'dummy' findclose DM> CB> function to match? Or does that function actually need to do something DM>It's like fclose - you need to call it. And I noticed Win32 has the same DM>feature. :-) But I don't see anything in my findfirst/findnext that _needs_ to be explictly closed. The only OS structure that is ever open is via opendir(), readdir(), and closedir(). Those are OS specific functions, so if the OS needs thread protection, they should provide it. And my function does call 'closedir()' to release any stuff that the library implementation or OS needs to release. DM> CB> If you can explain it a bit better, I'm willing to see what I can do DM> CB> before I post my next and hopefully final version of findfirst/findnext DM>See dirport in snippets. :-) I'm looking at it right now, but I still don't see anything that _I_ need to do. Those dirport functions are based on the normal OS/2 versions of findfirst, findnext, and findclose. And OS/2's version needs to have things closed, hence findclose. But my portable ones don't use those. They do it directly with the POSIX functions opendir(), readdir(), closedir(). So, the only OS structure that _I_ am using is what's being provided by those POSIX functions. And I am explictly closing it when I'm done. If any additional OS protection needs to be done for those three functions, then the implementations should already be providing it. I just don't see anything that my implementation needs to call. Or anything it even _can_ call. I'm already calling closedir() when I'm done, and the three POSIX dir functions are the only three OS resources I'm using. The only thing I can think of, that you might be meaning, is that in the D-Flat itself, if you chose to use the OS/2 versions, I need to put a couple of 'FIND_CLOSE' in there in case the user choses to use native ones instead of the portable ones. For other OSs, it just expands to an empty macro, but on OS/2, it expands to the findclose(). And in my portable ones, I should provide an empty findclose() function in case somebody with an OS/2 program already written wants to use my portable ones. Since the already written program will use findclose(), I need to provide one as well, even though my own findfirst / findnext don't actually need to be 'closed'. Due to the nature of the POSIX opendir(), readdir(), and closedir(), the OS structures will automatically be closed when the file matching is done. I'm sorry, but I just don't see what code I need to add. I can easily add 'dummy' functions for compatability with OS/2. I don't mind doing that at all. But I just don't see what my 'findclose()' function should actually _do_. Since closedir() is already being called, I just don't see anything else that I can do. I'm not using OS/2's versions of findopen() and findclose(), so I don't need to call os/2's findclose() because the OS requires it. And when findnext gets done, when it can't find any more matches, it automatically closes the only OS resource it is using. I assume you still have the findfirst/findnext code I posted before. If you can actually write code to do the findclose(), I'll add it to mine and repost the whole thing (which I need to do anyway). But I just don't understand what mine would need to do. .... Unless you are meaning I should provide a findclose() in case the user _stops_ doing more findnext()'s and the directory never gets closed! That didn't even occur to me until I'd already written the rest of the message, because D-Flat does all of the matches, until there are no more, at which point findnext automatically closes the directory. This is definetly a bug. Under DOS it doesn't matter, but the problem is still there. Just like if you kept opening new files and never closed them. However, this doesn't have anything to do with OS/2 being a multi-threaded OS, so I don't think this was really what you were talking about, and why. void FindClose(struct FFBlk *fb) { if (fb->DirPtr) closedir(fb->DirPtr); fb->DirPtr=NULL; } --- QScan/PCB v1.19b / 01-0162 * Origin: Jackalope Junction 501-785-5381 Ft Smith AR (1:3822/1) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00482 Date: 05/01/98 From: JANIS KRACHT Time: 02:04pm \/To: ALL (Read 1 times) Subj: New Arrivals at PDN HQ! Today, Friday 01-05-98, < TOPIC: 239 C LANGUAGE Ref: F5G00483 Date: 05/01/98 From: DARIN MCBRIDE Time: 06:27pm \/To: CAREY BLOODWORTH (Read 1 times) Subj: FINDFIRST & FINDNEXT CB> Well, the findnext does close the dir, by using closedir(). So, as soon CB> as the search ends, the OS/2 directory gets closed. The only other OS CB> functions that get used are stat() and the localtime, neither of which CB> would need to be closed. How is opendir/closedir implemented in the RTL of OS's which have the findfirst family? Usually by using the findfirst family. So you're going to majorly impact these platforms which probably have highly(!) optimized findnext routines by not using them. CB> And findfirst/next itself shouldn't care whether multiple searchs are CB> going on or not, because all of their data comes from pointers you pass CB> to it, or local stack data. In each case, that data would change when a CB> thread changes, so those functions wouldn't notice. But those pointers are going to point to the OS/2 or Win32 filefind "handle" which allows it to know which thread of searching is going on. CB> But I don't see anything in my findfirst/findnext that _needs_ to be CB> explictly closed. The only OS structure that is ever open is via CB> opendir(), readdir(), and closedir(). Those are OS specific functions, If findfirst is made public (available outside of D-Flat functions), it needs the close, even if close is merely a dummy on some platforms. CB> so if the OS needs thread protection, they should provide it. And my CB> function does call 'closedir()' to release any stuff that the library CB> implementation or OS needs to release. It's not "thread" protection, per se, but a matter of being able to run multiple checks simultaneously... which usually only happens on multiple threads. CB> Those dirport functions are based on the normal OS/2 versions of CB> findfirst, findnext, and findclose. And OS/2's version needs to have If you are attempting to provide normal findfirst/findnext(/findclose) functionality, I would suggest using the built-in versions on platforms which support them. CB> But my portable ones don't use those. They do it directly with the CB> POSIX functions opendir(), readdir(), closedir(). So, the only OS Your portable ones DO use those... on platforms that have them. Unix, OTOH, is based on opendir/readdir/closedir. To provide such functionality on Win32 or OS/2, generally the RTL will layer over the *dir functions. CB> structure that _I_ am using is what's being provided by those POSIX CB> functions. And I am explictly closing it when I'm done. If any You're better off closing it when the user says to close it, as you recalled later. CB> additional OS protection needs to be done for those three functions, CB> then the implementations should already be providing it. During the closedir(), yes. CB> The only thing I can think of, that you might be meaning, is that in the CB> D-Flat itself, if you chose to use the OS/2 versions, I need to put a CB> couple of 'FIND_CLOSE' in there in case the user choses to use native CB> ones instead of the portable ones. For other OSs, it just expands to an Nah - if the user is using the OS/2 APIs, they should use them properly - you can't protect against the user's abuse like that. (Sorta like free'ing a new'd array...) CB> empty macro, but on OS/2, it expands to the findclose(). OS/2 and Win32 at least... CB> .... Unless you are meaning I should provide a findclose() in CB> case the user _stops_ doing more findnext()'s and the directory never CB> gets closed! That didn't even occur to me until I'd already written the CB> rest of the message, because D-Flat does all of the matches, until there CB> are no more, at which point findnext automatically closes the directory. :-) Yeah, well, when I'm looking for a certain file "manually", I'll go through *.specialextention looking for a file that starts with "MY_FILE_TYPE"... once I find the first one, I don't need to keep looking. :-) CB> This is definetly a bug. Under DOS it doesn't matter, but the problem CB> is still there. Just like if you kept opening new files and never CB> closed them. However, this doesn't have anything to do with OS/2 being CB> a multi-threaded OS, so I don't think this was really what you were CB> talking about, and why. Sure it does - I could be doing *.ex1 on one thread, and *.ex2 on another thread. :-) CB> void FindClose(struct FFBlk *fb) CB> { CB> if (fb->DirPtr) closedir(fb->DirPtr); CB> fb->DirPtr=NULL; CB> } Basically, yeah, that'd be about all you need, if you insist on using closedir on platforms where findfirst/findnext exist already... :-) --- * Origin: Tanktalus' Tower BBS (1:250/102) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00484 Date: 05/01/98 From: WIM KONING Time: 06:21pm \/To: ALL (Read 1 times) Subj: Problem.. He, All.. Well, I just started with Turbo C 2.0, and often the compiler says "Suspision Pointer Conversion in . . ." For example with Gets(Dir); Dir is decalered as char Dir[128]; Why? is that wrong? And, Somethimes when I start my program after a while QEMM jumps up with an error.. Do you need to declare memory for strings? With malloc or kind? And how does that works? I'm just doing it for (ehhhh) 4 days, now.. :-) Yours Sincerely, Wim *ProgInc* ... tam..tamma..tammag.....tamm..... --- * Origin: Smurfensoep met balletjes! (2:282/1.40) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00485 Date: 04/30/98 From: AUKE REITSMA Time: 08:42pm \/To: DARIN MCBRIDE (Read 1 times) Subj: free'ing memory Hi Darin, On 29 Apr 98, 08:26, you wrote to Auke Reitsma KS>> Just that I still think that the most obvious way to KS>> implement fopen() and friends is simply just do a malloc() + KS>> relevant magic and return the value of the malloc()... AR>> Well, as far as implementation goes I agree with that. DM> I disagree - if the implementation doesn't remember all of its DM> "pointers", how is it supposed to flush their buffers when the DM> program exits (as the standard seems to say it will)? Closing is DM> no problem, just close() every possible handle. It's the buffer DM> that the FILE struct points to that I'm talking about here - if DM> the RTL has lost track of the struct, how will it be flushed? So it should NOT loose track of it. Other than returning it it should also keep it itself somewhere in a (dynamic) array. How else ... ;-) AR>> It is just too bad that it was not efficient enough in real AR>> old DOS days. But even then a fopen()ed FILE pointer _still_ AR>> should be deallocated with fclose() ;-) DM> Right. However, the standard allows for exit() to fclose DM> everything for you... :-) There's no reason at all that exit() could not access abovementioned array and call fclose() on all its valid values. Greetings from _____ /_|__| Auke Reitsma, Delft, The Netherlands.