--------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00047 Date: 04/18/98 From: TOM TORFS Time: 01:34pm \/To: KIM LYKKEGAARD (Read 2 times) Subj: MIME Kim Lykkegaard wrote in a message to All: KL> Does anyone have a pice of code, to code/decode a MIME KL> msg.? A complete MIME parser would be rather complex. Do you perhaps mean just base64-transfer-encoding ? Probably all the info you need on MIME can be found in RFC-1341. greetings, Tom tomtorfs@village.uunet.be --- timEd/2 1.10+ * Origin: 80X86 BBS 32-15-24.62.32 V.34/V.FC (24h/24h) (2:292/516) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00048 Date: 04/15/98 From: BILL GODFREY Time: 04:09pm \/To: TOM TORFS (Read 2 times) Subj: The rules [1/2] On 01 Apr 98, Tom Torfs snarfled at All and muttered thus: TT> 3) Discussion of C programming for illegitimate reasons (viruses, TT> crashware, etc.) is not permitted for the obvious liability TT> potential. May I suggest a slight modification. Pieces of code which demonstrate mistakes, (such as how it can be dangerous to dereference un-initialised pointers), along with an example, could be called "crashware". Or maybe not. What do you think? --- Spot 1.3a Unregistered * Origin: (2:2500/702.25@FidoNet) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00049 Date: 04/16/98 From: GEORGE WHITE Time: 08:43am \/To: JASEN BETTS (Read 2 times) Subj: Best sort algorithm [2/4 Hi Jasen, You wrote to Herman: JB>I'm not fully satisfied with it, as it will jumble up elements with the same JB>key value (this is not noticeable here) , I would prefer it to keep them n JB>their original order, I know there's a tweak to do this, I just can't hink JB>what it is. There is no way round this that I know of with quicksort, or Shell sort and Comb sort. None will maintain existing ordering and so are unsuitable for multiple key sorts. In those cases using a fast sort (one of the above) for the first key, followed by an insertion or selection (but not the selection sort using exchanges posted by Tom and Herman as a fast bubble sort) sort for subsequent key(s) is probably best. George * SLMR 2.1a * Wastebasket: Something to throw things near. --- Maximus/2 3.01 * Origin: DoNoR/2,Woking UK (44-1483-717905) (2:440/4) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00050 Date: 04/17/98 From: DAVID NOON Time: 09:09pm \/To: JASEN BETTS (Read 2 times) Subj: Liquorice Allsorts In a message dated 04-13-98, Jasen Betts said to All about Licorice Allsorts Hi Jasen, JB>Here's some more noise on the subject of sort algorithms. And interesting reading it was, too! [snip] JB>... and the winner is rg_qsort by a small fraction over the library JB>function. No surprises there. JB>Bubblesort, isertion etc: Don't do this at home -ah- work :) JB>My QuickerSort is beginning to look sick too. If you poll C_PlusPlus you will have seen the "evolution" of Quicksort routines being posted by me. This weekend I will post median-of-three pivot selection, and next Monday I'll remove recursion. This will bring it to the same level of algorithmic refinement as Ray Gardner's code. JB>SHELLsort may be faster with a more efficient swap routine. It needs a better chosen gap, too. Try Ray Gardner's Shellsort from SNIPPETS. JB>F-Bubble and insertion are the fastest on sorted lists, but that's about JB>all they have going for them. Both the bubble sorts have nothing going for them. Insertion sort is OK on very small arrays (rule-of-thumb: no more than 7 or 8 for large structures, 15 or 16 for integers). JB>All of these algorithms will be slower when sorting more complex JB>structures like arrays of pointers to strings or structs etc. Naturally. [TANSTAAFL] JB>Well, I learned that even with tiny arrays Qsort has a speed advantage, JB>and with it provided as a library function, and in snippets there's not JB>much excuse for not using it. Actually, there is. The calling interface for qsort() is woeful. [For "compatibility", Ray Gardner's code uses the same calling sequence.] This causes the comparison and swap operations to be called rather than inlined, which slows things down. This, in turn, is why I have been posting templates in C++ in the other echo. The calling sequence is simpler (easier to use) and the compiler can generate inline code for overloads of < and > operators. Unfortunately, once I am ready to post a comprehensive benchmark program it will be in C++, not C, and consequently will be in the C_PlusPlus echo. Regards Dave ___ * MR/2 2.25 #353 * On a clear disk you can seek forever --- Maximus/2 3.01 * Origin: DoNoR/2,Woking UK (44-1483-717905) (2:440/4) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00051 Date: 04/24/98 From: TOM TORFS Time: 05:04pm \/To: ADAM MAJER (Read 2 times) Subj: MIME Adam Majer wrote in a message to All: TT>A complete MIME parser would be rather complex. Do you perhaps mean just TT>base64-transfer-encoding ? AM> Instead of posting the code, would someone simply post the stucture AM> of the MIME transmistion (or file if it's saved on disk)? The RFC-1341 on MIME I have here is over 200 KB long and therefore way too large to post in the echo. I'll email it to you if you provide me with an address. greetings, Tom tomtorfs@village.uunet.be --- timEd/2 1.10+ * Origin: 80X86 BBS 32-15-24.62.32 V.34/V.FC (24h/24h) (2:292/516) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00052 Date: 04/24/98 From: TOM TORFS Time: 05:03pm \/To: MICHAEL MCGAVIN (Read 2 times) Subj: Getting the command line Michael McGavin wrote in a message to All: MM> Is there an easy way from within a program to get the complete MM> command line that was used to run the program? Not in a remotely reliable manner, AFAIK. For DOS you could try to have a look at PSP:80h and further, but since this is also the default DTA and you never know what the compiler's startup code did to it, I wouldn't recommend it. MM> I'd like to be able to keep all the whitespace and so on intact, MM> which is why I can't just merge together parameters passed through MM> the main() function. I don't really need the program filename MM> itself, or any whitespace up to the beginning of the first MM> parameter. Put your commandline parameters in double quotes ("") and the whitespace should be left intact. greetings, Tom tomtorfs@village.uunet.be --- timEd/2 1.10+ * Origin: 80X86 BBS 32-15-24.62.32 V.34/V.FC (24h/24h) (2:292/516) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00053 Date: 04/23/98 From: NEIL HELLER Time: 09:15pm \/To: ALL (Read 2 times) Subj: CALLING CONVENTIONS I'm familiar with using the reserved word PASCAL to modify the order in which formal parameters are placed on the stack. Does anyone know if the PASCAL keyword also affects who is responsible (the caller or the called function) for cleaning up the stack after the called function exits? * KWQ/2 1.2i * --- FLAME v1.1 * Origin: Port Chicago's Loading Dock - 510-676-5359 (1:161/204) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00054 Date: 04/19/98 From: ROGER SCUDDER Time: 09:55pm \/To: ELIJAH RICHARD (Read 2 times) Subj: Nested loop Hello Elijah. 18 Apr 98 18:36, Elijah Richard wrote to All: ER> @REALNAME: Buu Huynh Or should I write, Hello Buu ? ER> I'm using a book called "C by Examples" and on lesson 14 it ask me to write ER> a program that would print this by using nested loop: ER> A ER> AB ER> ABC ER> ABCD ER> ABCDE ER> This is what I have: ER> void main() { ER> int count, Ascii; ER> for(count = 1; count <= 5; count++) { ER> for(Ascii = 65; Ascii ........ ER> This is where I got stuck. I don't know what the test expression should be ER> for the second one. Also, I really don't know if I should use the ++ or --. ER> Can any of you elite help me here? Please? Rather than just giving you the answers, I'll try to help you understand how a nested for loop works. First realize that the outer loop controls the rows and the inner loop controls the columns and prints the characters. The loop should look like this: for ( count = 1; count <= 5; count++ ) { for ( ascii = 65; ascii < count + 65; ascii++ ) printf( "%c", ascii ); printf( "\n" ); } One quick comment: I used printf because your book doesn't introduce putchar for a few more chapters. For single character output putchar would require less overhead and would be prefered to printf. Now let's run through the loop and see exactlly what is happening... count 1 2 3 4 5 ascii 65 65,66 65,66,67 65,66,67,68 65,66,67,68,69 print "A" "AB" "ABC" "ABCD" "ABCDE" When the program starts, count is assigned the value 1 and the condition is evaluated. 1 is less than or equal to 5, so control is passed to the inner loop. The value 65 ( 65 == 'A' ) is assigned to the variable ascii and the condition is evaluated. 65 is less than 65 + count (count is equal to 1) so the printf is executed and the letter 'A' is printed. After the body of the inner loop has executed the variable is incremented ( 1 is added to ascii ) and the condition is evaluated. 66 is not less than 1 + 65 so control is passed to the next line of the outer loop and a newline is printed. After the body of the outer loop has executed the variable is incremented ( 1 is added to count ) and the condition is evaluated. 2 is less than or equal to 5, and control is passed to the inner loop. Again ascii is assigned the value 65 and the condition is evaluated. 65 is less than count ( now equal to 2 ) + 65, the printf is executed and 'A' is printed. ascii is incremented and the condition is evaluated. 66 is less than count + 65, the printf is executed and 'B' is printed. ascii is incremented and the condition is eveluated. 67 is NOT less than count ( 2 ) + 65 so control falls through and a newline is printed. This process continues until count is equal to 6. --- Msged/2 4.10 * Origin: New Potato Caboose BBS, Upper Darby, PA, USA (1:273/404@fidonet) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00055 Date: 04/20/98 From: NEIL HELLER Time: 09:05pm \/To: CHRISTOPHER BUTLER (Read 2 times) Subj: NASTY PROBLEM? NH> When I compile the DLL in debug mode and then download some information NH> (with the C++ program suite also compiled in debug mode), everything NH> works well and I have nothing but dollar signs in my eyes. However,.. CB> Have you recompiled the C++ program for the new DLL? It turned out that I was failing to return a boolean TRUE at the very end of a function ... but it took literally hours to track down. What I was interested in is if anybody knows of an easier way to debug problems when: 1) dealing with multiple language modules, 2) not being able to step through the code as with a debugger. I finally narrowed down the possibilities by stepping through the C++ (non-communications) code in virtually every call-back situation. In an event-driven scenario that can be hell. * KWQ/2 1.2i * --- FLAME v1.1 * Origin: Port Chicago's Loading Dock - 510-676-5359 (1:161/204) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00056 Date: 04/22/98 From: MICHAEL MCGAVIN Time: 02:33pm \/To: ALL (Read 2 times) Subj: Getting the command line Hi All, Is there an easy way from within a program to get the complete command line that was used to run the program? I'd like to be able to keep all the whitespace and so on intact, which is why I can't just merge together parameters passed through the main() function. I don't really need the program filename itself, or any whitespace up to the beginning of the first parameter. I'd like to be able to do it under DOS using DJGPP for which I get the feeling might work differently from most DOS-based compilers. If there's a more normal way to do it though which works everywhere except DJGPP, I can probably get access to some other compilers. Thanks for any help which would be greatly appreciated. Mike. email: zog@sans.vuw.ac.nz ICQ# 11017662 --- GoldEd 2.50 UNREG * Origin: DARK SKIES Astronomy -- Wgtn, NZ. +64-4-235-6887 (3:771/1560.201)