--------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECK00001 Date: 08/12/97 From: CAMERON CLARK Time: 03:48am \/To: ALL (Read 3 times) Subj: !!StackControl??? How do you increase the stack size using BC++4.51 for DOS and 16 bit targets? The only thing I've found is for 32bit targets and just stack checking under debugging. --- GEcho 1.00 * Origin: Digital OnLine Magazine! - (409)838-8237 (1:3811/350) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECK00002 Date: 08/14/97 From: LEIGH MORRESI Time: 09:18pm \/To: HERBERT BUSHONG (Read 3 times) Subj: WATCOM and C++ Sorry but... HB> Look in the online help. a quick search for _asm should show you how. HB> _asm { lalala }; I looked, theres nothing there to that relevance.... I love Watcom, I espicially use it for windows programming that is were it is at its best... but damn inline assembly??? aaaaaargggggh!.. cant find anything... oh well. from leigh.. (ps: thanxs for your help!) --- FMail/386 1.20+ * Origin: Comms Barrier BBS +61.3.9585.1112, +61.3.9583.6119 (3:632/533) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECK00003 Date: 08/15/97 From: JERRY VINOKUROV Time: 10:37am \/To: JAVIER KOHEN (Read 3 times) Subj: Programming -> On 06-Aug-97, Jerry Vinokurov wrote to All about Programming. -> -> JV> Is anyone out there a game programmer, or a graphics programmer? -> -> I have a little experience, try to email me. -> I'm developing a few PD graphic classes, I can send 'em to you, too. -> BTW, do you get the GAMEDEV echo? Check it out. -> -> Javier Kohen [The_Crusher] http://jkohen.base.org -> ... Lower the force field. Worf -> -!- CrusherTag 0.3.2. -> --- Terminate 5.00 UnReg -> * Origin: The King of The Ring (4:900/748.3) Thanx a lot... but what is this GAMEDEV thing? I asked my sysop about it and he doesnt know what it is... --- WILDMAIL!/WC v4.10 * Origin: The Mystic Tower BBS Santee, CA (619) 596-0271 (1:202/330.0) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECK00004 Date: 08/15/97 From: JERRY COFFIN Time: 10:09am \/To: GERRY DANEN (Read 3 times) Subj: C++ or ASM? On (11 Aug 97) Gerry Danen wrote to Erik Warmelink... [ talking about the `volatile' keyword ] GD> I don't understand why all screen output would be removed due to GD> optimization. Can you explain, please? Most compilers have an optimization called dead code elimination. This analyzes the code to figure out whether there's code that can never possible execute. This can come in handy in a situation like: if (sizeof(int) < 4) do_this(); else do_that(); Now, obviously the size of an int can't change during run time. What you're doing is nearly the sort of thing you'd typically do with the preprocessor, but you can't use sizeof() in a #if, so you'd have to change things considerably to let the preprocessor handle this. The alternative is for the compiler to eliminate the code that's never going to get used, as well as eliminating the code for an if() that's always going to make the same decision. Some compilers that do relatively sophisticated analysis can also determine that some variable you're writing to never actually has that result used. In this case, they again eliminate the code that writes to that variable. The problem arises with writing to the screen because it appears to the compiler that what you write to the screen never gets read again. Therefore the compiler assumes that the result was never used, and optimizes out the code that does the writing. Obviously here we run into a problem: even though you (nearly) never have code that reads values from the screen buffer, YOU read the output on the screen. You have to inform the compiler that the act of writing to this memory is important EVEN when it appears to the compiler to accomplish nothing. A similar situation arises when something other than the program can modify some memory. Under normal circumstances, a program is free to assume that if it writes something into a memory location, it'll get the same value back out if it reads that same location. Likewise, it's free to assume that if it reads one value one time, that unless it writes to that location, it'll get the same value if it reads the same location again. This is an important optimization: it's MUCH faster to store those values in registers when possible. However, if you're dealing with something like the keyboard buffer, it doesn't apply. For instance, if you read the keyboard buffer pointers one time, they might indicate that no key has been pressed. After you press a key, one of the pointers will change to indicate that a key HAS been pressed. Each time you want to check for a keypress, you have to read the data from memory - you can't simply assume that if you read it once, it won't change until the program changes it. (most programs will NEVER change it, but it changes constantly, each time the user presses a key on the keyboard.) Later, Jerry. ... The Universe is a figment of its own imagination. --- PPoint 1.90 * Origin: Point Pointedly Pointless (1:128/166.5) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECK00005 Date: 08/15/97 From: JERRY COFFIN Time: 10:29am \/To: DARIN MCBRIDE (Read 3 times) Subj: C++ or ASM? On (12 Aug 97) Darin Mcbride wrote to Gerry Danen... DM> (I said something about _me_ not being the moderator... Tom doesn't DM> read the echoes he moderates!) I'd be interested in how somebody moderates an echo without reading it, though if anybody has a reply, it should sent privately... GD> You're over my head here. If I am using the modem under NT, say GD> in a bbs program, would I get down to the stack level? DM> Nope - you just use DosRead (OS/2) or whatever under NT, and be happy DM> that the device driver is handling that for you. You don't worry DM> about contention - the device driver does. It's harder to find under NT, since it's cleverly hidden under the name ReadFile. DM> Well, no one said multithreaded programming was easy. Not anyone *I* DM> know has said that anyway. :-) Actually, with proper use, threads can make some programs tremendously easier to write. For instance, in a simulation you typically have separate things (typically objects) that each act more or less independently from other things. Without threads, you typically make a big table of things, and step through the table, making each thing carry out whatever actions it's supposed to do. With multiple threads, you simply spawn off a thread for each object you care about, and let the OS handle the part with stepping through each one and making them run in turn. However, multiple threads makes volatile even MORE important rather than less so. Even though you use mutexes or critical sections to control access to shared objects, you still have to inform the compiler that these objects may change without its knowledge, so it has to actually read/write the value from/to memory rather than caching it in a register. DM> So... I take it you don't want to write device drivers? ;-) I don't particularly. I do it fairly regularly, but out of necessity... Later, Jerry. ... The Universe is a figment of its own imagination. --- PPoint 1.90 * Origin: Point Pointedly Pointless (1:128/166.5) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECK00006 Date: 08/15/97 From: JERRY COFFIN Time: 10:23am \/To: BENJAMIN L MCGEE (Read 3 times) Subj: couple of ?'s On (11 Aug 97) Benjamin L Mcgee wrote to All... BL> ...manifest is initialized by one of the following constructors... BL> manifest::manifest(){ BL> filename = new char[FILENAME_MAX]; BL> while (!select(filename, FILENAME_MAX - 1)); BL> mstreamp = new ifstream(filename); BL> } BL> manifest::manifest(const char* manfile){ BL> filename = new char[FILENAME_MAX]; BL> strncpy(filename, manfile, FILENAME_MAX - 1); BL> mstreamp = new ifstream(filename); BL> } BL> How do I handle errors in opening the ifstream? exception handling was invented largely to deal with errors in ctors. There's really no other clean method available. BL> Is it a good idea perhaps, to just allocate space for filename within BL> the constructor and then handle everything else in a manifest::init() BL> member? That would seem redundant to me but perhaps overloading BL> constructors is already redundant. I would avoid this if at all possible. It's nearly inevitable that if you require a separate call to initialize the class that at least occassionally somebody will forget to call it. One of the major strengths of C++ is its ability to ctors and ensure that as soon as an object comes into existence, it WILL be initialized. Separating the two cripples this capability. Later, Jerry. ... The Universe is a figment of its own imagination. --- PPoint 1.90 * Origin: Point Pointedly Pointless (1:128/166.5) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECK00007 Date: 08/15/97 From: JERRY COFFIN Time: 10:39am \/To: NEIL HELLER (Read 3 times) Subj: DATABASE STUFF On (12 Aug 97) Neil Heller wrote to Jerry Coffin... [ talking about ODBC ] NH> Is the one centralized DLL generic or specific to a platform? Well, it's obviously specific to a platform that can load and execute the DLL. E.g. you can't very well load and execute a Win32 DLL under, say, OS/400, OS/2 or UNIX. Later, Jerry. ... The Universe is a figment of its own imagination. --- PPoint 1.90 * Origin: Point Pointedly Pointless (1:128/166.5) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECK00008 Date: 08/15/97 From: JERRY COFFIN Time: 10:03am \/To: HERBERT BUSHONG (Read 3 times) Subj: fstream identifying mode On (13 Aug 97) Herbert Bushong wrote to Jerry Coffin... ::> class my_stream : public fstream { ::> int mode_; HB> I don't know if there's a way to use it, but the filebuf class already HB> has a mode member (protected:) which stores this information. Still, HB> deriving a new class similar to the above seems a safer/easier way to HB> capture the parameter... At the moment it certainly is. Once things settle down completely and we have some decent documentation on the iostream classes, I think it'll be likely that you can retrieve this fairly easily from filebuf. However, right now, the iostream classes included with compilers vary extremely widely. Some are nearly unchanged since the ARM, others are nearly current with the draft standard. Unfortunately, most are somewhere in between, often with extensions of their own mixed in. While this sort of thing is nearly inevitable while a standard is being written (the same thing happened while the C standard was being written) and for a few years after it's finished, it's still a pain to deal with. Code reuse is wonderful, but in some cases it's just not worth the trouble, and writing your own new code is easier. Later, Jerry. ... The Universe is a figment of its own imagination. --- PPoint 1.90 * Origin: Point Pointedly Pointless (1:128/166.5) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECK00009 Date: 08/15/97 From: JERRY COFFIN Time: 07:01pm \/To: JAVIER KOHEN (Read 3 times) Subj: C++ or ASM? On (11 Aug 97) Javier Kohen wrote to Cameron Clark... JK> Yeah, fine, I knew it. I was complaining about cast's cosmetics :-) JK> In C, I would have written just "scr = (volatile char *) 0xA0000000;", JK> about half the size. It's more or less intentional that casts are bulky and ugly; this tends to encourage people to find alternatives. If an alternative to casting exists, it's usually an improvement. Later, Jerry. ... The Universe is a figment of its own imagination. --- PPoint 1.90 * Origin: Point Pointedly Pointless (1:128/166.5) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECK00010 Date: 08/15/97 From: JERRY COFFIN Time: 07:03pm \/To: DOMENICO FERRARI (Read 3 times) Subj: First Program On (11 Aug 97) Domenico Ferrari wrote to Anthony Tibbs... DF> Ok, I'll tell you more about it... DF> The program is a simple cronograph for grand prix for Windows 3.1 or DF> 95... First of all, I'd point out that Windows 95 is a fairly poor environment for doing precise timing. About the only thing around that's worse is Windows 3.1... DF> when I press Enter in a window start a crono for the total time race DF> and when I press space in another window I'd like to have lap time DF> and average speed... Hmm...if you want it, I've got a finished version of something vaguely similar to this that I'd be happy to netmail or email to you (or to anybody else who wants it, for that matter.) Like most Windows programs, it's pretty big for posting here, but if a number of people were interested I s'pose I might consider it. Quite a bit of the code is straight out of MS' AppWizard and ClassWizard though... Later, Jerry. ... The Universe is a figment of its own imagination. --- PPoint 1.90 * Origin: Point Pointedly Pointless (1:128/166.5)