--------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F2U00005 Date: 02/24/98 From: CARLTON WALTERS Time: 02:03pm \/To: CAREY BLOODWORTH (Read 2 times) Subj: INTEGER OVERFLOW thanks but this message was posted a long time ago How do i get rid of it ? --- FastEcho 1.46 * Origin: House of Fire BBS - Toronto - (416)601-0085 - v.34 (1:250/536) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F2U00006 Date: 02/24/98 From: CARLTON WALTERS Time: 02:06pm \/To: JASEN BETTS (Read 2 times) Subj: i got another simple ques how do i get rid of the message i posted? --- FastEcho 1.46 * Origin: House of Fire BBS - Toronto - (416)601-0085 - v.34 (1:250/536) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F2U00007 Date: 02/24/98 From: BRADLEY MACOMBER Time: 01:04pm \/To: JONATHON WELLER (Read 2 times) Subj: MUD Programming *** Quoting Jonathon Weller to All dated 02-22-98 *** > MUD stands for Multi User Dungeon. If anyone else is interested in > programming one please mail me. > > CheerZ, > CaPtaAiN Jon my main project is a game that is like a MUD in every way except that it has 3D graphics. what are ya tryin to do? --- T.A.G. 2.7c Standard * Origin: The Wizards Realm BBS 1-713-946-7315 1:106/7315 (1:106/7315) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F2U00008 Date: 02/23/98 From: NORMAN DODGE Time: 07:02am \/To: MIKE STAPLETON (Read 2 times) Subj: CRC.C Hello Michael! First of all In Cfg.C: enum RetVal { NO_PROBLEMS, ERR_FOPEN, ERR_MEM /* The comma after ERR_MEM is incorrect /* }; /* Take the comma out not ANSI C /* While compiling CRCParam.C I got the following error message: Including :CMS:ORCA:LIBRARIES:ORCACDefs:stdio.h Including :CMS:ORCA:LIBRARIES:ORCACDefs:stdlib.h Including :CMS:ORCA:LIBRARIES:ORCACDefs:string.h Including :ram5:CRCModel.h Including :ram5:CFG.h Compiling main 84 argv += cfgf; ^ the operation cannot be performed on operands of the type giv en Compiling atobool Compiling fileCRC Compiling printCRC 1 error found. Any Idea why? Norman * 2qwk! 2.04 * --- FLAME v1.1 * Origin: TechAlliance BBS Renton Wa. 206-277-6070 (1:343/133) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F2U00009 Date: 02/24/98 From: RICHARD MCCONNELL Time: 03:06pm \/To: ADAM MAJER (Read 2 times) Subj: C Well I went out and got the C++ for Dummies and it said that you should know the basics of C before you go on in the book. So it has no basic's in it. And now I need help with the basics of C....... --- Maximus 2.01 * Origin: Access Info Kingston (613)547-2479 (1:249/104) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F2U00010 Date: 02/19/98 From: VICTOR KEMP Time: 02:16pm \/To: MICHAEL STAPLETON (Read 2 times) Subj: Re: qsort-ing a struct MS> this? In many cases, it is better to build a separate array which MS> indexes the main struct array. This index can be a simple array MS> holding the integer index of each struct in the array, or it can be MS> an array of pointers. Sounds like a simplified version of a linked list, but without the links. I might try that if the other way proves too slow, but seeing as I had changed to qsort from BUBBLE SORT and it worked fast enough with that, I don't think speed is going to be t Thanks for the suggestion anyway, but I'm not about to make my code infinitly more complicated if it doesn't make any noticable difference. ... Windows Error 005: Multitasking attempted. System confused. --- Maximus 3.01 * Origin: The Ultimate (3:771/340) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F2V00000 Date: 02/25/98 From: STEVE IGREJAS Time: 06:16pm \/To: ALL (Read 2 times) Subj: Basics Hello All, Can anyone tell me the Basics to C? I really want to learn. Thanks for your help. --- QuickBBS 2.85 GoldBase * Origin: >>>Xanadu BBS<<< New Bedford Ma. (508)995-9876 (FIDONET 1:329/889) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F2V00001 Date: 02/23/98 From: BILL BIRRELL Time: 10:44am \/To: TOM TORFS (Read 2 times) Subj: Has anyone? Hi Tom, > JD> Other programs could just be spawned from the running one. > Do you _really_ want to do this ? I doubt it :-) Good question, Tom. A program that spawns other programs takes on one of the functions of an operating system anyway. A program that spawns operating systems that in turn spawn programs takes on the one of the functions of an O/S selector. A hypervisor is the end result of all this. The Intel and Motorola microprocessors are certainly designed with a proper supervisor in mind, and embedded C is a natural for it, but so far the limitations of the standard PC platform reduce the concept from the sublime to the gor blimey. Best wishes, Bill. --- * Origin: bill@escan.demon.co.uk (2:2504/200) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F2V00002 Date: 02/23/98 From: BILL BIRRELL Time: 04:09pm \/To: NEIL HELLER (Read 2 times) Subj: WHAT'S HAPPENING HERE? Hi Neil, > Can someone explain to me just which variables were > implicitly cast by > the compiler (I used MSVC 5.0)? Would result2 have > been different had > I placed a left paren following the '=' and a right > paren before the > '+'? Was it necessary to place 'F' in each of the two > places used > (after the constants to which they referred)? To all of that, individually and collectively, no. It *is* a little unusual to make assignments before you have finished declaring variables, though. Bill. --- * Origin: bill@escan.demon.co.uk (2:2504/200) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F2V00003 Date: 02/24/98 From: CAREY BLOODWORTH Time: 10:15pm \/To: WAYNE GREER (Read 2 times) Subj: Bit functions WG>I store these values to a file. The program reads/writes them fine, WG>but I'm wondering if someone else writes a supporting program in a WG>different complier, and using this typedef struct format, will their WG>compiler read this 'file' data properly? No guarantee. That's true of any program reading binary data. WG>'bit function' only complier dependent for it's memory locations? WG>or might they reverse the bit's, or some other bizare thing I'm not WG>aware of. If you're careful (and it sounds like you have tried to be), it will probably work for most compilers, but there is absolutely no guarantee about it. Like so many other things in C, it's 'implementation defined.' The standard doesn't even require the bit fields to be in a certain order within the int (ie: high->low or low->high bits first). Bit fields may or may not overlap from one 'addressable unit' to the next. WG>This was much easier than to OR the results to a char and trying to keep WG>track of bit positions for true/false, it got far too complicated as I WG>have dozens, perhaps hundreds of options/flags to turn on/off It can help. However, depending on what you do with those fields, it may not be very program efficient. It may slow the program, and may actually take more program space than you save in data space. If all you are doing is setting, clearing, and testing single bit (ie: _un_signed bit field of width 1), it can be fast, but if you are doing anything else, it probably isn't. If you need portability and the space saving of bits, you could always just go ahead and use chars or something, and then just use a simple macro or function. If space isn't really that big of a concern, just use an array of unsigned chars, and that way you can do them like: Options[Flag1]=ON; and so on. Just as easy as bitfields, and at most, it'll take up only 8 times as much memory. Even if you have a thousand options, unless you have many copies of those options at the same time, it shouldn't cause a problem. Here's an excerpt from the c standard. A bit-field may have type int, unsigned int, or signed int. Whether the high-order bit position of a "plain" int bit-field is treated as a sign bit is implementation-defined. A bit-field is interpreted as an integral type consisting of the specified number of bits. An implementation may allocate any addressable storage unit large enough to hold a bit-field. If enough space remains, a bit-field that immediately follows another bit-field in a structure shall be packed into adjacent bits of the same unit. If insufficient space remains, whether a bit-field that does not fit is put into the next unit or overlaps adjacent units is implementation-defined. The order of allocation of bit-fields within a unit (high-order to low-order or low-order to high-order) is implementation-defined. The alignment of the addressable storage unit is unspecified. A bit-field declaration with no declarator, but only a colon and a width, indicates an unnamed bit-field. As a special case of this, a bit-field with a width of 0 indicates that no further bit-field is to be packed into the unit in which the previous bit-field, if any, was placed. Each non-bit-field member of a structure or union object is aligned in an implementation-defined manner appropriate to its type. Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared. A pointer to a structure object, suitably cast, points to its initial member (or if that member is a bit-field, then to the unit in which it resides), and vice versa. There may therefore be unnamed holes within a structure object, but not at its beginning, as necessary to achieve the appropriate alignment. There may also be unnamed padding at the end of a structure or union, as necessary to achieve the appropriate alignment were the structure or union to be a member of an array. --- QScan/PCB v1.19b / 01-0162 * Origin: Jackalope Junction 501-785-5381 Ft Smith AR (1:3822/1)