--------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00239 Date: 04/14/98 From: JOHN GARDENIERS Time: 05:44pm \/To: SIMON AVERY (Read 2 times) Subj: The availability of cprintf() (was: -get17:44:4904/14/98 Hi Simon, -=> 10 Apr 98 22:11, Simon Avery wrote to John Gardeniers <=- SA> I wanted to know how to output coloured text and neglected to mention SA> I was using PCC. A dozen replies of "use cprintf() or cputs()" none SA> of which worked. If you still use PCC you may (or may not) care for a few library routines I wrote while using it myself. I'd have to dig it out but I seem to recall doing something about colour printing to the screen. Let me know if you want them. They're probably small enough to send as Netmail, unless you have Internet access. ttyl, >>> Fuse (fuse@one.net.au) >>> ... Never replicate a successful experiment. --- GoldED/W32 3.00.Beta3 UNREG * Origin: The Cubby House, I C it but I don't believe it (3:634/391) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00240 Date: 04/14/98 From: RICHARD VETO Time: 02:27am \/To: BRUCE WEDDING (Read 2 times) Subj: Re: Programming typedef struct { ARMOR armor; WEAPONS weapons; WAND wands } PLAYER_INVENTORY; I kind of figured out the union won't work. Now with this superstructure, do I embed it into the player structure? And if so, how do I access this? Player[Idx].PLAYER_INVENTORY.armor[x] ? You can do it that way, but I think I would actually add these structs to an existing player structure. In any event, I think you've demonstrated that you know how to access the elements. Thanks for the reply... but I found that as I was trying to do it this way, there was way too much overhead involved. With this method, PLAYER_INVENTORY would have to be an array. Within each element of the array, only one could actually be used. ie, the first element in the array could only be either armor, weapon or wand etc... I'm not sure if I'm doing this in an effecient manner, but what I've done is created int arrays within the player structure.. ie. int armorinv[4] which simply hold the number of the xth element in the armor array (which is a structure). At the same time, I think I'll make the 0th element of armorinv to be the wielded armor/weapon. I find that there is less code as a result of this. Correct me if I'm wrong. This is such a huge project and I could be overlooking the simplest of things at this point.. :) Richard ___ Blue Wave/QWK v2.12 --- Telegard/QWK v3.02/mL * Origin: Underworld Systems V - (416)782-1980 (1:259/416) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00241 Date: 04/09/98 From: ANDREW FRANK Time: 02:19am \/To: HERMAN SCHONFELD (Read 2 times) Subj: Re: Best sort algorithm [2/4] As Herman Schonfeld had made known to All, on 06 Apr 98 16:10:10, I quote. I'm not entirely sure of your objectives with this test, if memory constraints are insignificant, some of these comments are useless. Assorted comments and declarations have been removed. HS> char data[1000][4]; HS> char save[1000][4]; HS> void QKSORT() HS> { HS> /* Implementation of QUICKSORT algorithm */ HS> char temp[20]; HS> static int sl[1000][2]; I'd say that this is somewhat overstated. In a worst case (memory wise) the list will continually be split into groups of 2, the pivot, and the rest. With a group of 1 or 0, the pivot, and the rest, the first group is sorted and can be forgot. Thus, the amount of temporary storage peaks 1/3 the total list size in the worst case, so 334 would be enough. (more follows code) HS> l = 0; HS> r = lastone; HS> p = 0; HS> do HS> { HS> while(l < r) HS> { HS> i = l; HS> j = r; HS> s = -1; HS> while(i < j) HS> { HS> if (strcmp(data[i],data[j]) > 0) HS> { HS> strcpy(temp,data[i]); HS> strcpy(data[i],data[j]); HS> strcpy(data[j],temp); HS> s = 0 - s; HS> } HS> if (s == 1) HS> i++; HS> else HS> j--; HS> } HS> if (i + 1 < r) HS> { HS> p++; HS> sl[p][0] = i + 1; HS> sl[p][1] = r; HS> } HS> r = i - 1; HS> } HS> if (p != 0) HS> { HS> l = sl[p][0]; HS> r = sl[p][1]; HS> p--; HS> } HS> } HS> while(p > 0); HS> } Something to consider is swapping the value in the middle of the list with the value at the start of the list before each pass. In your example, a perfectly sorted or unsorted list would be a worst case. By doing that, the unsorted/sorted list would become a best case, and the worst case would be an unlikely random occourance. It would certainly help for sorted, or partially sorted lists, but otherwise adds a little overhead. As a matter of personal preference, I also prefer a recursive quick sort, it's a lot less code, normally much less memory hungry as the quick sort is normally far from worst case, but a little slower. Now for a performance gain, when the list segments get to a certain point, the full blown quick sort gets a little heavy and bloated. I prefer to call a bubble sort or linear insertion sort to finish segments when the get down to about 10-20 entries. Then again, your quick sort is about as lean as they get for short lists. All in all, the method I use is normally a little faster, normally uses less memory, and requires a little more code. Andrew Frank ... C code. C code run. Run, code, run.... PLEASE! --- Blue Wave/386 v2.30 [NR] * Origin: fks Online! * Mississauga, ON Canada (1:259/423) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00242 Date: 04/09/98 From: ANDREW FRANK Time: 02:40am \/To: HERMAN SCHONFELD (Read 2 times) Subj: Re: Best sort algorithm [4/4] As Herman Schonfeld had made known to All, on 06 Apr 98 16:18:12, I quote. 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 HS> has too many caveats that I can't be bothered working around - It is a HS> very quick sorting algorithm however (fastest), but it's not worth the HS> hassle (for me anyway). I don't suppose you'd have psudo code for that or anything. I'm curious as to how it would work. So far I've just been tweeking the quick sort. And how could a sorting algorithm possibly be OS dependant? I suppose I'd have to see it. Andrew Frank ... Engineers keep their erections up --- Blue Wave/386 v2.30 [NR] * Origin: fks Online! * Mississauga, ON Canada (1:259/423) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00243 Date: 03/27/98 From: ALEXIS TCACH Time: 01:21pm \/To: ALL (Read 2 times) Subj: Read keyboard Hola All! Does somebody know how to read 2 (or more) keys from the keyboard at the same time ??? Thanks !! Salute !!! ALEX --- FMail/386 1.0g * Origin: =[Cryptanic BBS TLD 22:30 07 hs Tel : 709-5028]= (4:900/470.8) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00244 Date: 04/15/98 From: DARIN MCBRIDE Time: 08:22am \/To: HERMAN SCHONFELD (Read 2 times) Subj: Event Handler HS> Most compilers accept non-standard code. And most HS> people understand non-standard code aswell. DM>Are you sure about either, or is it just YOUR compiler(s)? I seem to DM>recall you going on about some non-standard code DM>(cprintf?) that happens DM>to work on YOUR compilers, but not really _ALL_ current compilers. HS> How many other compilers need cprintf? There's no use None. Not standard. HS> whining if someone is too stupid to realize that HS> cprintf() is only useful within DOS. Hence, all DOS This echo is not just for those who already know C, but for those learning, too. Your exclusion of those learning is one of the reasons that you are slowly being twitted by anyone who knows better. HS> compilers have it (the ones that I know of anyway, and HS> that list is big). If a DOS compilers doesn't have it, I believe I've seen a list of four or five already posted that don't - and they're DOS compilers. HS> then it would most likely contain an equivalent. Why? What happened to printf anyway? HS> Another error in your previous asseration is your HS> assumption that cprintf() is in the standard. It is not. I never made any such assumption. You're assuming about my assumptions. (Here's a hint: you were talking about "accepting non-standard code", and I just brought up one of your "non-standard" issues again.) HS> SomeType *mytime = (SomeType *)malloc(sizeof(SomeType)) HS> when, HS> SomeType *mytype = malloc(.... etc HS> compiles. Even though ANSI-C++ forbids void * DM>We're not talking about C++, are we? I thought this was the C echo. HS> Same concept applies to C. You did realize that, didn't you? Nope - because ANSI C allows conversion from void* to any other pointer type - this has nothing to do with C. Please stay on topic. HS> conversion it still works, doesn't it? I could go on HS> and on about it but I assume you get the idea. DM>Yes, I get the idea that you have no clue about what standards mean. HS> Just as I suspected. Your brain failed to synapse such infantile logic. Something like that. Now, if you'd stop using infantile logic... --- * Origin: Tanktalus' Tower BBS (1:250/102) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00245 Date: 04/13/98 From: AUKE REITSMA Time: 10:46pm \/To: BILL BIRRELL (Read 2 times) Subj: -getch() Hi Bill, On 08 Apr 98, 11:52, you wrote to Auke Reitsma >> Hmng ... where is the "return ;" ;-) BB> Well spotted! The disgusting thing is that it compiled and BB> ran when tested .... :-( Sure ... That's C for you ;-) BB> If there are any readers who can't put these two messages BB> together, then I am not going to do it for them. How unkind of you, my friend ;-) BB> All I can say is that cprintf() was in the book like that, so BB> I'm not the only one whose brain occasionally switches off. :-) BB> No excuse, Guv! Yep! Been there, done that. Daily in fact. Though I usually can shove it nder the carpet before anyone notices ;-) Greetings from _____ /_|__| Auke Reitsma, Delft, The Netherlands. / | \ -------------------------------------- --- GEcho 1.00 * Origin: Home by the C (Auke.Reitsma@net.hcc.nl) (2:281/400.20) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00246 Date: 04/13/98 From: AUKE REITSMA Time: 10:58pm \/To: MARK TRICKETT (Read 2 times) Subj: Stucture tags Hi Mark, On 09 Apr 98, 12:28, you wrote to Bob Stout & Auke Reitsma MT> Hello Bob & Auke, the basics of a structure and accessing it MT> are not too difficult, but I have some questions about some of the MT> parts. MT> I have given the struct both a stucture type name and a MT> structure variable, and then give the working instance in the MT> program yet another name which is an array of structs. What is MT> necessary, and some of the simpler why? ... Just a few notes: MT> struct STAGE_DATA _This_ STAGE_DATA is a TAG. Which means that it can and should be used to distinguish this type of struct from other types of structs. MT> { MT> char stage[10], /* stage number (letter for transport) ... MT> restrictions[10]; /* other restrictions */ MT> } stage_data; And _this_ stage_data is a real variable name. Also known as a 'definition' of that variable -- and occasionally and incorrectly as a declaration of that variable. You mixed (correctly!) two independent aspects: The struct STAGE_DATA { ... }; just describes what that struct is. And the struct STAGE_DATA stage_data; defines one variable of that type of struct. To make it difficult you can also mix it with typedef's: typedef struct STAGE_DATA stage_data_t; Then you could define one variable of that struct STAGE_DATA type by: stage_data_t stage_data; Summary: "struct STAGE_DATA" and the typedef'ed "stage_data_t" are data types; "stage_data" is a variable; and "STAGE_DATA" by itself is a 'tag' that distinguishes the struct from other structs. Greetings from _____ /_|__| Auke Reitsma, Delft, The Netherlands. / | \ -------------------------------------- --- GEcho 1.00 * Origin: Home by the C (Auke.Reitsma@net.hcc.nl) (2:281/400.20)