--------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: E4400003 Date: 04/02/97 From: DOMINIK SZEWCZYK Time: 11:47pm \/To: ALL (Read 5 times) Subj: wolf3d Hi! I've been playing around with the WOLF3D source code and it does not compile right :( the code compiles but the game is very screwed up...can someone help me? I'll be glad enough to give the source...l8r --- Blue Wave/TG v2.12 * Origin: "The Shareware Library" (815) 727-6072 Joliet,IL (1:2222/700) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: E4400004 Date: 04/02/97 From: JERRY JANKURA Time: 10:26pm \/To: MIKE WALKER (Read 5 times) Subj: Streams MW>Jerry Jankura wrote in a message to Mike Walker: MW> JJ> Mike - Let me offer a few advantages of stream I/O MW>The notation looks a little strange at first. Expecially for someone not used MW>to C++ yet. :-) Can you tell me what you mean by "in-core" storage? Are ou MW>refering to writting to memory? You're correct on both counts - in-core storage is writing to a memory buffer (but doesn't using the term "in-core storage" sound better?) and the idea of using the left and right shift operators to insert and extract characters from a stream first looks strange. MW>So then if I was displaying a user defined record of some kind I could extend MW>cout to display/store my record type? This sounds pretty pretty neat, I'll MW>have to look into this a little. Yep, if you write an insertion operator for an object, you can insert it into a stream just like you do a character or integer. But, the trick to remember is that you MUST write the operator. MW>Really I did not realize the stdio was parsed at run time. This would be a MW>definate plus for stream io wouldn't it? I think so. Also, one fellow also mentioned that you can't run into problems caused by pushing the wrong kind of data onto the stack for the format expression. --- * OLXWin 1.00b * * DisneyLand: A people trap operated by a mouse. --- InterEcho 1.19 * Origin: PC-Ohio PCBoard * Cleveland, OH * 216-381-3320 (1:157/200) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: E4400005 Date: 04/03/97 From: KURT KUZBA Time: 11:45am \/To: BALOG PAL (Read 5 times) Subj: THINGS BP> KK> private: BP> KK> char *name; BP> KK> name = char*(NULL); BP> 2 questions: BP> a) why do you use the cast? BP> b) why do you use NULL? BP> I'd probably use BP> name = 0; bp>.... Just force of habit, really. Since I mean to return a pointer of type char, that is precisely what I am going to do. The compiler will not likely complain at name = 0, true. It is simply mindless adherence for no real reason other than that my superstitious rituals comfort me. :) Since the code that is output is probably identical, I really didn't accomplish anything except possibly the removal of a mostly harmless ambiguity from the source. > ] I'm so relieved... My IQ test came back negative........... --- * Origin: *YOPS ]I[* 3.1 GIG * RA/FD/FE RADist * Milwaukee, WI (1:154/750) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: E4400006 Date: 04/02/97 From: NICK SHREDERS Time: 12:12pm \/To: HERMAN SCHONFELD (Read 5 times) Subj: Re: DJGPP optimizations HS> Does anyone know the best combination of DJGPP optmization directives HS> to compile a real-time texture mapper? HS> I currently use :- gcc -O3 -fexpensive-optimizations HS> -fkeep-all-inlined-fuctions -fthread-loops -funroll-all-loops -fomit-frame-pointer and -s if you dont plan on debugging. HS> Also, can someone give me the best directives to compile for a :- HS> Pentium Pro Pentium 486 512 cache 486 256 cache -m486 --- Telegard v3.02/mL * Origin: Kitchen Sink * Lawrence, KS * 913-749-9480 (1:299/122) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: E4400007 Date: 03/30/97 From: BORIS TERZIC Time: 10:55am \/To: PETER SHELOMOVSKY (Read 5 times) Subj: Watcom And the cosmic ballet continues... PS> Watcom docs or help information is really needed! What exactly do you need? PS> By the way is there any shell for it? (Except for WIN one) I believe there is an "IDE" called vi.exe in WC 10.6 for DOS, but that is THE worst IDE ever constructed. I myself use Aurora 3.0 for coding C under DOS, excelent syntax coloring, loads of options, very configurable, and you can of course compile source from within the editor and let it read the error file. :::[(,//.).common.hedgehog.(brought).to.Fidonet.by.(Boris.Terzic@rug.ac.be)]:: : :::::::::::::::[but the hedgehog can never be buggered at all]::::::::::::::::: ... "Ahhh, another bowl of chocolate frosted sugar bombs." - Calvin --- GoldED 3.00.Alpha4 UNREG * Origin: MESS.24/24.7/7.DemosScene/Coding/SF.(+32-3-772.69.25) (2:292/8139) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: E4400008 Date: 03/30/97 From: MARCO ALLARD Time: 04:31pm \/To: ALL (Read 5 times) Subj: Bitmap in OWL? Hello All, Can anyone tell me how to use a bitmap in a little program? I have to use OWL so it makes it even more difficult, I guess... The Question is: How do I define a bitmap, and how do I use it in my program... (the bitmap is for example arcade.bmp from c:\windows directory) I know how to do it with a homemade bitmap, but how do I do it with an external one (that looks much much better than mine) Thx in advance,.. Marco --- FMail 1.0g * Origin: UAPoint 20 - Yeeeehaaaaa ! (2:292/628.20) On (02 Apr 97) Darin McBride wrote to Jerry Coffin... JC> DWORD static __stdcall RealThreadProc(void *theClass) { JC> // Here we invoke the virtual function in the class whose JC> // address we passed into here... JC> // JC> return ((ThreadBase *)theClass)->ThreadProc(); JC> } DM> Perhaps adding RTTI support to ensure we ARE dealing with a ThreadBase DM> pointer here... :-) It can't be done: you can't use RTTI on a pointer to void. RTTI has the same problem you do at that point: it doesn't know enough about the pointer to find out anything. RTTI works perfectly well when you know you have a pointer to (at least) a base class, and want to know whether it's really a pointer to a derived class. However, to do that bit of magic, it follows the class' vtable pointer back to the vtable, and looks at extra information the compiler hides there, to check which sort of derived object it might be. However, if what we have really isn't a pointer to the class at all, then trying to find the vtable isn't going to work, and trying to look at magic stuff the compiler hid in the vtable isn't going to work either. If we have the wrong sort of pointer to start with, even the attempt at using RTTI could very well get our program shut down. JC> I'm not saving the thread ID, because it's pretty close to useless. JC> I'm not even sure why they have thread IDs at all. DM> I dunno about Win32, but I know that in OS/2 you can raise other DM> thread's priorities, query their state (blocked, running, etc.), block DM> them and, , kill them. (Mind you killing threads has the DM> expected side effect of basically destabilizing the entire process and DM> the entire process should then shut down immediately, preferably with DM> a bit of grace.) All of this requires the thread ID. Under Win32, most, if not all, of this involves the thread handle instead of the ID. DM> I'm pretty sure there is a fair bit of other stuff. (For example, in DM> my semaphore objects, I need my thread ID in order to figure out if I DM> am the thread who owns the semaphore or if it is someone else... I can DM> then also figure out who it is so I can kill it ) Umm...I'm a bit lost as to what you're trying to get at here, though it does give the glimmer of an idea of a use for the thread ID: it allows you to identify the thread that owns something _without_ giving a thread that receives it any other capabilities such as changing your priority, killing you, etc. (Those who've read Patricia McKillip might notice a rough parallel to the "use name" vs. "true name" in some of her books. It always amazes me how many parallels there are between programming and many of the stories about magic. For those who don't understand a bit of what I'm babbling about here, I'd reccomend reading _A Wizard of EarthSea_ - quite good reading, IMO.) 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: E4400009 Date: 04/03/97 From: JERRY COFFIN Time: 09:31am \/To: DARIN MCBRIDE (Read 5 times) Subj: Multithreading member-functions On (02 Apr 97) Darin McBride wrote to Jerry Coffin... JC> DWORD static __stdcall RealThreadProc(void *theClass) { JC> // Here we invoke the virtual function in the class whose JC> // address we passed into here... JC> // JC> return ((ThreadBase *)theClass)->ThreadProc(); JC> } DM> Perhaps adding RTTI support to ensure we ARE dealing with a ThreadBase DM> pointer here... :-) It can't be done: you can't use RTTI on a pointer to void. RTTI has the same problem you do at that point: it doesn't know enough about the pointer to find out anything. RTTI works perfectly well when you know you have a pointer to (at least) a base class, and want to know whether it's really a pointer to a derived class. However, to do that bit of magic, it follows the class' vtable pointer back to the vtable, and looks at extra information the compiler hides there, to check which sort of derived object it might be. However, if what we have really isn't a pointer to the class at all, then trying to find the vtable isn't going to work, and trying to look at magic stuff the compiler hid in the vtable isn't going to work either. If we have the wrong sort of pointer to start with, even the attempt at using RTTI could very well get our program shut down. JC> I'm not saving the thread ID, because it's pretty close to useless. JC> I'm not even sure why they have thread IDs at all. DM> I dunno about Win32, but I know that in OS/2 you can raise other DM> thread's priorities, query their state (blocked, running, etc.), block DM> them and, , kill them. (Mind you killing threads has the DM> expected side effect of basically destabilizing the entire process and DM> the entire process should then shut down immediately, preferably with DM> a bit of grace.) All of this requires the thread ID. Under Win32, most, if not all, of this involves the thread handle instead of the ID. DM> I'm pretty sure there is a fair bit of other stuff. (For example, in DM> my semaphore objects, I need my thread ID in order to figure out if I DM> am the thread who owns the semaphore or if it is someone else... I can DM> then also figure out who it is so I can kill it ) Umm...I'm a bit lost as to what you're trying to get at here, though it does give the glimmer of an idea of a use for the thread ID: it allows you to identify the thread that owns something _without_ giving a thread that receives it any other capabilities such as changing your priority, killing you, etc. (Those who've read Patricia McKillip might notice a rough parallel to the "use name" vs. "true name" in some of her books. It always amazes me how many parallels there are between programming and many of the stories about magic. For those who don't understand a bit of what I'm babbling about here, I'd reccomend reading _A Wizard of EarthSea_ - quite good reading, IMO.) 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: E4500000 Date: 04/03/97 From: THOMAS MAEDER Time: 06:59pm \/To: AARE TALI (Read 5 times) Subj: Static? Say what? AT> BC++ 3.1 complained that multiple storage classes specified. OK, AT> is static. But what is second? Section 9.3 of the Annotated Reference Manual says that "Member functions [...] have external linkage by default [unless they are declared inline, static or virtual]". This is similar to non-member functions declared in a header file. AT> he is contradicting with himself, 'long float' = 'double', 'for' = ' AT> something, while(), { ... do something }', wtf is 'signed' or 'auto' No. These are C features. He always wanted to keep C++ as compatible as possible to C. Thomas --- MM 1.0 #0113 Member: International Brotherhood of Tagline Thieves! * Origin: McMeier & Son BBS (2:301/138) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: E4500001 Date: 04/04/97 From: JOE CANHOTO Time: 01:30am \/To: CLIFF RHODES (Read 5 times) Subj: file size That is what makes it so weird. I've brought this to the attention of some of my old profs. and they agree. I guess a greater issue would be Microsoft's way affecting standards before they happen. Just look at static and reinterpret casting. They sorta jumped the gun on it and now ,boom, it's in the latest draft??? This was something that was bound to happen anyway though consider Stroustrup's critisim's of C's cast. l8r We are all objects of the class human BUT I don't like my default nstructor! --- * Origin: Multiboard * 519-660-3574 * Internet * 4GB * (1:2401/0) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: E4500002 Date: 04/03/97 From: CAREY BLOODWORTH Time: 09:51pm \/To: HERMAN SCHONFELD (Read 5 times) Subj: DJGPP optimizations HS>Does anyone know the best combination of DJGPP optmization directives to HS>compile a real-time texture mapper? HS>I currently use :- HS>gcc -O3 -fexpensive-optimizations -fkeep-all-inlined-fuctions HS> -fthread-loops -funroll-all-loops About the only three really useful optimizations are the -O3, -m486, and -ffast-math. Everything else comes with conditions where they can generate massive code bloat, and even slow down the program (because of cache misses, etc.) For example, although a loop has loop overhead, unrolling the loop too much (or all the way) will cuase far more cache misses than what you might gain by removing the loop overhead. The more complex the loop, the less benefit. As a general rule, unrolling a loop 2-4 times will get the best result. That is just a general rule. There are exceptions. Same thing with inlining large functions and so on. They can cause loss of cache locality and massive code bloat. Once an inline function gets beyond a half dozen lines or so, function call overhead is minimal, plus since the function is now always at a fixed location, it might be cached, where as before, each new occurence would have to be read from slow main memory. The point is, there are conditions to most optimizations. You shouldn't do them expecting 'the more optimization swithces the better'. HS>Also, can someone give me the best directives to compile for a :- HS>Pentium Pro HS>Pentium HS>486 512 cache HS>486 256 cache Same switches. GCC is not the best at optimization. Plus, it only generates 486 code, not 586+ code. Plus, the 486 code tweaking it does is for a _generic_ 486. What that means is that it aims roughly down the middle of the field. But there are a lot of different 486s, and for some of them, the code GCC generates with -m486 can be less than optimal. --- QScan/PCB v1.19b / 01-0162 * Origin: Jackalope Junction 501-785-5381 Ft Smith AR (1:3822/1)