--------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00361 Date: 04/21/98 From: KURT KUZBA Time: 11:30am \/To: JASEN BETTS (Read 2 times) Subj: LICORICE ALLSORTS JB> HS> Have you tried compiling it on an optimising compiler? JB> Testing Sort algorithms - this is a 32bit compiler this time. JB> 5000 items random sorted reversed JB> QuickerSort 0.33 0.20 2.93 JB> rg-qsort() 0.19 0.15 0.16 JB> qsort() 0.20 0.14 0.15 JB> SHELLsort 0.83 0.17 0.44 So, then, one may as well use the standard qsort() and not worry too much about it, eh? If you need a faster sort for a specific purpose, you will have to test all algorithms in your specific case anyway. For general sorting, one may as well just use qsort() and save the development time and bother. > ] This will make no sense whatsoever. Continue (Y/N)?......... --- * Origin: *YOPS ]I[* 8.4 GIG * RA/FD/FE * Milwaukee, WI (1:154/750) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00362 Date: 04/20/98 From: DAVID NOON Time: 09:18pm \/To: KALLE SOIHA (Read 2 times) Subj: Bubble & Squeak Sorting In a message dated 04-18-98, Kalle Soiha said to Carey Bloodworth about Bubble And Squeak Sorting Hi Kalle, KS>Very likely. Quicksort is not the best algorithm for small KS>amounts of data. Bubblesort is best for small (<100 items KS>of data or so) inputs. We have very recently seen benchmarks in this echo that say that this assertion is wrong. Very wrong. KS>Also, a bubblesort is very simple to KS>write (not that quick is much harder, but still). We also have posted routines that are simpler & smaller than bubble sort. You have arrived a little late for this party. This echo and C_PlusPlus have been replete with sorting algorithms for about 2 months now. We have had a little mathematical theory (mostly from me), a fair amount of code (mostly from the SNIPPETS collection and George White, and Herman Schonfeld) and an awful amount of [useless] folklore. You have just added to the last. Would you like to post some code to redress the balance? We haven't seen Heapsort or Mergesort yet. Nor have we seen Herman's legendary radix sort (or the radix exchange sort). I was planning on coding these algorithms too, but since you have jumped in perhaps you would like to try one (or more). Regards Dave ___ * MR/2 2.25 #353 * Curiosity didn't kill the cat, I got him with a 12 uge.. --- Maximus/2 3.01 * Origin: DoNoR/2,Woking UK (44-1483-717905) (2:440/4) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00363 Date: 04/21/98 From: SIMON AVERY Time: 01:17pm \/To: ROGER SCUDDER (Read 2 times) Subj: Shell V. Shell "As if by magic, Roger Scudder appeared!" DN>> Dave DN>> RS> What is Team PL/I ? Do you program in PL/I for a living or RS> something? I was under the impression that it was not the most RS> desireable language to work with. I think it's quite good if you want the Y2K problem to pay for your Ferrari... ') (Ok, Tom - just going...) Ciao, Simon ... "Bother," said Roger, as he was trapped in the airtight vault ... Tag-O-Matic V.13F Under Test... --- FMail/386 1.22 * Origin: My other computer is a PC as well. (2:255/90) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00364 Date: 04/20/98 From: ANTHONY TIBBS Time: 05:52pm \/To: CAREY BLOODWORTH (Read 2 times) Subj: TURBO VISION CB> Do you have a regular e-mail address? (Juno, etc.) If so, I could try CB> and uuencode it and send it there. (I don't have FIDO net-mail send, so CB> I can't do that.) D-Flat v20 (the last 'official' release) is about CB> 150k zipped. It is the source for the 'library' and the example program CB> 'memopad'. It also includes a short description of the classes and CB> messages you can use. It doesn't include an executable, but it compiles CB> easily with Turbo C++ 3.0 (the only 16 bit DOS compiler I have.) It CB> should compile okay with any other 16 bit dos compiler. Sure, "tibbs@offsbbs.com". UUENCODE or MIME is fine. --- Maximus 3.01 * Origin: The Tibbs' Place BBS - Pvt - Ottawa, ON, Canada (1:163/551.22) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00365 Date: 04/17/98 From: JOHN DUMAS Time: 12:57pm \/To: ALL (Read 2 times) Subj: lost disk I bought the Sterling Castle "C" Function Library long ago with the intention of some day looking into it because the source code was included. Subroutines which are close. But, tend to be larger and more time consumming to comprehend than functions. But, I lost the disk somewhere, although, I do have the book the box I could photocopy and fax but the company is probably long gone. Snippets has some nice subroutines, But, does anyone recommend any libraries I may find and look at like: int SendEmail( char *ToWho, char *Message ) { sprintf( command,"%s %s %s","net send",ToWho,Message ); return (system( command )); }; This is one of mine, such as it is. I would like to look at simular *short* functions. Sorry, but I learn best in small bites. I do have access to internet. While I have it here, system,spawn,exec, do not work if compiled as win 16. How would this simple function be done for win 16. ... If you think you're confused now, just wait until I explain it. --- Blue Wave/DOS v2.20 [NR] * Origin: The Witch City BBS *Salem,MA [978]745-1689 *Hayes 28.8 (1:101/301) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00366 Date: 04/12/98 From: DOMINIC BATTRE Time: 05:50pm \/To: HERMAN SCHONFELD (Read 2 times) Subj: RE:Best sort algorithm [4/4] Hi. HS> Hopefully this has answered all questions concerning "best sort HS> algorithm". I did leave out RADIX sort however, because I feel it would HS> defeat the purpose of a "best sort algorithm". It is OS dependant and has HS> too many caveats that I can't be bothered working around - It is a very HS> quick sorting algorithm however (fastest), but it's not worth the hassle HS> (for me anyway). Have you ever tested naturalmergesort? It's OS independant and it's fast: O(N log N) - but it takes a log of memory: O(N) Domi Ausgezeichnet mit dem Funstar: http://home.t-online.de/home/D_Battre --- FIPS/32 v0.99b W95/NT [M] * Origin: Vorlaeufig letzt Zeile dieser Mail (2:2457/235.12) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00367 Date: 04/14/98 From: CAREY BLOODWORTH Time: 09:22pm \/To: ANTHONY TIBBS (Read 2 times) Subj: TURBO VISION AT>CB> versions, a C++ version (D-Flat++), and a larger, more complete C AT>CB> version (D-Flat). And a partial C++ wrapper (DFWrap) to go around the C AT>I don't mind using the C version. It's not great C programming, but you don't have to really look too closely at it to just use it. AT>CB> (You can get the 16 bit DOS D-Flat from the DDJ ftp site.) AT> Yet another "go to this FTP site" to get it message. I don't HAVE I don't either. It can be frustrating at times. I gave the ftp site simply because I don't know any BBS that has it. Over the past few years, I've seen earlier versions on a number of boards, but not the last few versions. The Simtel cds had earlier version (I think it was v15), which certainly works well enough for you to look at. The last update he did was May 95, version 20, and it might be on that month's code distribution, so you might look around for that on some BBSs. (Probably called ddj9505.* or ddj0595.* or ddj95-may.*, etc.) AT>that access. Take care, Do you have a regular e-mail address? (Juno, etc.) If so, I could try and uuencode it and send it there. (I don't have FIDO net-mail send, so I can't do that.) D-Flat v20 (the last 'official' release) is about 150k zipped. It is the source for the 'library' and the example program 'memopad'. It also includes a short description of the classes and messages you can use. It doesn't include an executable, but it compiles easily with Turbo C++ 3.0 (the only 16 bit DOS compiler I have.) It should compile okay with any other 16 bit dos compiler. I tried to send you a copy from Juno (free internet e-mail) to you through the fido gateway, but Juno couldn't seem to find the gateway.... --- 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: F5G00368 Date: 04/14/98 From: CAREY BLOODWORTH Time: 09:22pm \/To: SIMON AVERY (Read 2 times) Subj: [TURBO VISION] To: SIMON AVERY Subject: [TURBO VISION] SA> CB> (You can get the 16 bit DOS D-Flat from the DDJ ftp site.) SA>Which is where, exactly? Dunno the exact URL. The DDJ site itself is www.ddj.com, but I don't know where the D-Flat stuff is. (I don't have net access.) For all I know, the files might only be on the ftp site (ftp.ddj.com) and not even available from the Dr. Dobbs Journal web page. Let me go see if I can find Al Steven's message..... Okay, here it is. He told me that the latest version of D-Flat (v20), D-Flat++ (v4), and the C++ wrapper for D-Flat (dfwrap) is on ftp.ddj.com in the packages/dflat directory. I would assume that Quincy (the C subset interpeter using D-Flat) would be in the packages/quincy directory. And I-Mail (a program using dfwrap) is probably in packages/imail. --- 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: F5G00369 Date: 04/14/98 From: CAREY BLOODWORTH Time: 09:22pm \/To: SIMON AVERY (Read 2 times) Subj: D-Flat fixes 1/3 To: SIMON AVERY Subject: D-Flat fixes I thought you might also be interested in the bug fixes that I've done so far. I don't have a list of changes for it to run under DJGPP. I started out making minimal changes, so I could just do a DIFF, but a short way into that, I realized that what I should really do is isolate all the system specific stuff and make D-Flat itself generic. As a result, I've been doing quite a bit of cut & pasting, etc. In the not too distant future, I'll be needing somebody to try compiling it with other compilers & platforms, though. Anyway, here is my current list of fixes. I'm up to 17 and I've got a couple more problems jotted down that I 'need' to work on. (And I haven't even actually _DONE_ anything with D-Flat yet. All this has been just trying to compile it, and just minor running and experimentation with the sample MemoPad program. By the time I get done, I may not have the energy to do anything with this!) ------BUGS.TXT A list of bug fixes. This includes only genuine bugs (most of which were fatal), and not changes to fix compiler warnings or provide some security for user callable functions. Note that due to other changes I've made, the line numbers are only approximate. 1) In Fixhelp.c, in FindHelp(), the parameter pointer nm might be a NULL, in which case the strcmp() will fail with a protection mode violation. The solution is to simply test it and return a -1, indicating that it wasn't found. Add line 43: struct helps *thishelp = FirstHelp; if (nm==NULL) return -1; /* CEB: BUGFIX */ while (thishelp != NULL) { if (strcmp(nm, thishelp->hname) == 0) 2) In dialbox.c, in the ControlProc(), at the SETFOCUS command, it was setting the oldfocus visible. This was causing problems in the combobox (such as printer setup) where mouse clicks wouldn't select a port, and if you tried to chose a port a second time, the pop down list box wouldn't appear completely, or disappear later. Line 726: if (GetClass(oldFocus) == APPLICATION && NextWindow(pwnd) != NULL) pwnd->wasCleared = FALSE; DefaultWndProc(wnd, msg, p1, p2); /* SetVisible(oldFocus); */ /* CEB: BUGFIX */ 3) In memopad.c, in selectfile(), it was looping through all the windows to see if you already had that file open. But not every window has an extension (ie: some are set to NULL), so the stricmp() was causing a protection mode violation. Add line 196: /* --- see if the document is already in a window --- */ WINDOW wnd1 = FirstWindow(wnd); while (wnd1 != NULL) { if (wnd1->extension) /* CEB: BUGFIX */ 4) in memopad.c, in fixtabmenu(), it was modifying the menu selection to reflect the current tab setting (2, 4, 6, 8), and then checking to see if that menu was infocus, and if so, repaint. The problem was, when starting the program, NO window was infocus, so the GetClass(inFocus) caused a protection mode violation. Add line 535: if (cp != NULL) { cp = strchr(cp, '('); if (cp != NULL) { *(cp+1) = cfg.Tabs + '0'; if (inFocus) /* CEB: BUGFIX */ 5) In message.c, in VisibleRect(), it's looping through the parent windows (until it's NULL). The problem was that the line right before that _used_ pwd to get its rectangle. That caused protection mode violations. The solution was to move that line to right after the while(...) statement, and I can also remove the part of the last line of the loop that simply uses pwd to get the rectangle, which is what the line I'm moving does. Lines 509-517: RECT prc; while (pwnd != NULL) { prc = ClientRect(pwnd); /* CEB: BUGFIX */ if (TestAttribute(pwnd, NOCLIP)) break; rc = subRectangle(rc, prc); if (!ValidRect(rc)) break; pwnd = GetParent(pwnd); /* CEB: BUGFIX */ 6) In popdown.c, in KeyboardMsg(), it's finding the shortcut key of a selection. But there might not be one. It's using strchr, which returns NULL when it doesn't find one. The next line goes ahead and dereferences that pointer to make the key lower case. Line 215: int sc = cp ? tolower(*(cp+1)) : -1; /* CEB: BUGFIX */ if ((cp && sc == c) || (a && sc == a) || pd->Accelerator == c) { 7) in popdown.c, in PopDownProc(), at LB_SELECTION, It doesn't make sure that wnd->text and wnd->menu aren't NULL. This can occur if you are at a menu selection that doesn't have any popdown items (such as if you select the 'window' menu and you don't have any windows open.) Lines 296: case LB_SELECTION: if (wnd->text) /* CEB: BUGFIX */ if (*TextLine(wnd, (int)p1) == LINE) return TRUE; if (wnd->mnu) /* CEB: BUGFIX */ wnd->mnu->Selection = (int)p1; break; 8) In Combobox.c, in ListProc(), it was declaring some variables and also initializing them. The problem was that the initialization wasn't valid for all the commands the routine might be given. The solution is simple, although not elegant. Simply remove those vars and initialization and put them only in the sections where they are needed. (I could have simply checked to see if those variables were valid before I initialized something that depended on it, but that would have required too many checks. This makes more sense.) Line 50: int ListProc(WINDOW wnd, MESSAGE msg, PARAM p1, PARAM p2) { /* CEB: BUGFIX. remove pwnd, db, and cwnd */ Line 85: case LB_SELECTION: { /* CEB: BUGFIX */ WINDOW pwnd = GetParent(GetParent(wnd)); WINDOW cwnd = ControlWindow(pwnd->extension, wnd->ct->command); rtn = DefaultWndProc(wnd, msg, p1, p2); (Continued to next message) --- 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: F5G00370 Date: 04/14/98 From: CAREY BLOODWORTH Time: 09:22pm \/To: SIMON AVERY (Read 2 times) Subj: D-Flat fixes 2/3 To: SIMON AVERY Subject: D-Flat fixes (Continued from previous message) Line 95: return rtn; } case KEYBOARD: { /* CEB: BUGFIX */ WINDOW pwnd = GetParent(GetParent(wnd)); WINDOW cwnd = ControlWindow(pwnd->extension, wnd->ct->command); switch ((int) p1) { Line 109: } break; } case LB_CHOOSE: { /* CEB: BUGFIX */ WINDOW pwnd = GetParent(GetParent(wnd)); WINDOW cwnd = ControlWindow(pwnd->extension, wnd->ct->command); SendMessage(cwnd, SETFOCUS, TRUE, 0); return TRUE; } (I told you it was simple, just not very elegant!) 9) In Text.c, in TextProc(), if GetControl(wnd) returns NULL, then cp2 would try to access via a NULL pointer. This bug has not yet occured, but I can see that it can because later in the code it checks to make sure that ct isn't NULL. Line 9: char *cp, *cp2; /* CEB: BUGFIX */ Add line 20: cp2 = ct->itext; /* CEB: BUGFIX */ len = Min(ct->dwnd.h, MsgHeight(cp2)); cp = cp2; 10) When creating a combobox, if you created more items than could be shown in the drop down window space, there was no way to select non-displayed items with the mouse. The solution is simply to add a line to PutComboListText() in combobox.c, which is what you call when you create the combobox to add all the items to be selected. Line 133: if (ct != NULL) { WINDOW lwnd = ((WINDOW)(ct->wnd))->extension; SendMessage(lwnd, ADDTEXT, (PARAM) text, 0); SetScrollBars(lwnd); /* CEB: BUGFIX */ 11) If you tried to mark a newly created, empty edit window / box, you would get a segmentation violation in textbox.c when it tried to reverse print a non-existant line. This was caused by ExtendBlock() in editbox.c subtracting a pointer to the begining of the line from a pointer to the end of the line. The problem was that it was using strchr() to find the end of line (a '\n'), and it returns NULL when there isn't one found. So, it was doing a NULL-pointer. The solution is to simply check the return from strchr and not do the subtraction, just set 'len' as zero. Line 225: int ptop = min(wnd->BlkBegLine, wnd->BlkEndLine); int pbot = max(wnd->BlkBegLine, wnd->BlkEndLine); char *lp = TextLine(wnd, wnd->wtop+y); char *elp = strchr(lp, '\n'); /* CEB: BUGFIX */ int len = 0; /* CEB: BUGFIX */ if (elp) len = (int) (elp - lp); /* CEB: BUGFIX */ x = max(0, min(x, len)); 12) When it was displaying a message box that didn't have a title (such as the yes/no exit box), it would give a protection violation because it didn't have a title (it was set to NULL) and then calling strlen() to take its length. The solution is to simply add a check for it in GenericMessage() in MSGBOX.C Line 151: MsgBox.ctl[0].dwnd.h = MsgHeight(msg); MsgBox.ctl[0].dwnd.w = MAX(MAX(MsgWidth(msg), buttonct*8 + buttonct + 2), (ttl?strlen(ttl):0)+2); /* CEB: BUGFIX */ 13) You couldn't use the left/right arrow keys to move between buttons (for example, the yes/no buttons in the 'exit memopad' window. You could use up/down, tab/backtab, but not left/right. This was caused by CtlKeyboardMsg() modifying the keys pressed, _but_ it was only changing the parameters. When the function returned, those changes were lost, so KeyboardMsg() never got the 'correct' keys. (I still don't know why keyboardmsg() didn't just deal with the keys it was passed, but ctlkeyboardmsg() is clearly in error, and at fault.) Also, since the keys are changed (to 'control_five' key macro) you have to add an extra case statement to keyboardmsg(). Since this routine has been _inoperative_ since version 13 of D-Flat (Jul 97), I wonder if there were any later 'fixes' to overcome various problems. Line 142: case SHIFT_HT: case CTRL_FIVE: /* CEB: BUGFIX */ case BS: case UP: PrevFocus(db); break; Line 571: static BOOL CtlKeyboardMsg(WINDOW wnd, PARAM *p1, PARAM *p2) /* CEB: BUGFIX */ Line 574: switch ((int) *p1) { /* CEB: BUGFIX */ Line 582: if (!((int)*p2 & ALTKEY)) /* CEB: BUGFIX */ Line 587: PostMessage(GetParent(wnd), KEYBOARD, *p1, *p2); /* CEB: BUGFIX */ Line 598: switch ((int) *p1) { /* CEB: BUGFIX */ Line 601: p1 = CTRL_FIVE; /* CEB: BUGFIX */ p2 = LEFTSHIFT; /* CEB: BUGFIX */ Line 607: p1 = CTRL_FIVE; /* CEB: BUGFIX */ p2 = LEFTSHIFT; /* CEB: BUGFIX */ Line 614: *p1 = '\t'; /* CEB: BUGFIX */ Line 618: *p1 = '\t'; /* CEB: BUGFIX */ Line 691: case KEYBOARD: if (CtlKeyboardMsg(wnd, &p1, &p2)) /* CEB: BUGFIX */ return TRUE; 14) When you resized the application window, the app window was never back in focus (as indicated by the double lined border). That meant that after you resized it, you couldn't type anything to it. Not a menu open, another resize, or even the 'exit'. It appeared that the keyboard had simply locked up. If you had a mouse, you could click on the application window to regain the focus. If you didn't, it was Big Red Button time! The problem occured because the (Continued to next message) --- QScan/PCB v1.19b / 01-0162 * Origin: Jackalope Junction 501-785-5381 Ft Smith AR (1:3822/1)