--------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECI00003 Date: 08/12/97 From: MICHAEL TOTH Time: 04:43pm \/To: RAJESH DHAWAN (Read 3 times) Subj: modem & serial ports RD> Hi: RD> RD> MT> Hi, i am looking for info on the 16550a chips in modems so that RD> MT> create a serial program. If any one can help me find anything o RD> MT> please let me know... RD> MT> RD> I can help. RD> Let me know more about what you want. RD> RD> Rajesh well i what to know every thing you could tell me.. like. what every bit of he register are for ex.. bit 1 is for the data to be sent.. . or anything that you think would be of any help... what i am trying to do is write a com program that i can do almost anything with.. Michael --- TriToss (tm) Professional 10.0 - #218 * Origin: Dark Lands, Granville MA 413-357-8688 (1:321/332.0) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECI00004 Date: 08/12/97 From: CHRIS DOWNS Time: 07:10am \/To: DARIN MCBRIDE (Read 3 times) Subj: Re: Sunir ventures into C DM> When I'm debugging, I often need: DM> char szBuf[128]; DM> sprintf(szBuf, "...", ...); DM> WinMessageBox(HWND_DESKTOP, szBuf, "function name", MB_OK, DM> ...) EW> Wouldn't EW> dbg("function name", ..., "...", ...); EW> be easier? Perhaps even DM> Heck, no. That would require writing a dbg function! Sometimes I DM> just need a quick peek, not a full-fledged debugging system. I'm not DM> writing a major software product from scratch, here, I'm adding new DM> functionality on to an old product, and need quick peeks into my code. Wouldn't TRACE be just what the doctor ordered????? --- Blue Wave/QWK v2.12 * Origin: St. Louis Users Group (1:100/4) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECI00005 Date: 08/12/97 From: CHRIS DOWNS Time: 07:10am \/To: NEIL HELLER (Read 3 times) Subj: Re: PRINTING POINTER VALU NH> char aStr[10] = "abcdefgh"; NH> char * aPtr = &aStr[5]; NH> cout << aPtr << endl; DM> You want: DM> cout << (void*)aPtr << endl; NH> Just an honest question: why, after aPtr was declared to be a pointer NH> to char, would you need to cast it in order to print the address NH> (contents of the pointer). There are many overloads for operator <<. There is one for int's, one for char's, one for char*'s, etc. The overload for the char* is designed to handle zero terminated character arrays. But there is also an overload defined to handle a void*. That version will print the value of the pointer. NH> Instead of a C-style cast, would it be preferred in that situation to NH> do: NH> cout << static_castaPtr << end; I don't believe that will compile. reinterpret_cast would compile. But you may well get a different output (thought the same value.) On my machine, the operator<<(void*) displays the answer in "pointer format" while operator<<(int) displays "plain old numbers". --- Blue Wave/QWK v2.12 * Origin: St. Louis Users Group (1:100/4) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECI00006 Date: 08/12/97 From: NEIL HELLER Time: 07:49pm \/To: JERRY COFFIN (Read 3 times) Subj: DATABASE STUFF JC> The general idea is that there's one ODBC DLL that centralizes JC> much of the ODBC capabilties, then there are drivers for individual JC> types of databases. Live and learn... Is the one centralized DLL generic or specific to a platform? * KWQ/2 1.2i * --- TMail v1.31.5 * Origin: Diablo Valley PCUG-BBS, Walnut Creek, CA 510/943-6238 (1:161/55) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECI00007 Date: 08/13/97 From: GERRY DANEN Time: 08:21am \/To: JERRY COFFIN (Read 3 times) Subj: C++ or ASM? JC> #include JC> int main(void) { JC> int _far *screen = (int _far *)MK_FP(0xb800, 0); JC> for ( int i=0; i<(80*25); i++) JC> *screen++ = ' '; JC> return 0; JC> } JC> I intend that it clear the screen. As long as I compile without JC> optimization, it does exactly that. _However_ if I tell Microsoft JC> VC++ 1.52 to use maximum optimization, it does absolutely _nothing_. I'll have to try that. Kinda lame... JC> The problem is that the compiler has "noticed" that I'm not "using" JC> any of the values I write into `*screen', so it simply doesn't write JC> them there anymore. If I change the declaration of `screen' to: JC> int _far volatile *screen /* ... */; JC> It clears the screen regardless of the level of optimization I decide JC> to use. JC> (disclaimer: this is demo code only. It't not intended for real use. JC> It definitely _won't_ work if you have a monochrome card installed. JC> If you have a color card installed, it's likely to cause a nuclear JC> catastrophe.) Don't worry, I have routines writing directly to video memory. No damage is done if you point to the wrong address. At worst you'll hang the machine real bad... Gerry Danen (gdanen@accessweb.com) C+Net BBS @ 403-477-9545 http://www.geocities.com/SiliconValley/Way/9823 2 years, 140 days, 15 hours, 52 minutes, and 0 seconds until January 1, 2000. ... There are 3 kinds of people: Those who can count & those who can't. --- Maximus 3.01 * Origin: C+Net BBS. Programming & Networking. (1:342/1017) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECI00008 Date: 08/13/97 From: GERRY DANEN Time: 08:24am \/To: DARIN MCBRIDE (Read 3 times) Subj: C++ or ASM? DM> Anyway, you would use volatile under DOS for global variables that are DM> modified by interrupts, or anything else modified by interrupts for DM> that matter. GD> Or another process? DM> Well, that's often difficult in DOS. Even when you can - NT or OS/2 - DM> each DOS session should be protected from each other. DM> (Hey, maybe THAT's where they get this "protected-mode" buzzword DM> from... ) You may have something there... GD> What about concurrent DOS windows?... DM> Are you asking about protected-mode systems? OS/2 & NT virtualize the DM> screen to prevent "bleeding" (a common thing back from DESQview days). DM> If you think you're pointing at the video, you aren't. The CPU, in the DM> current context, has been told that B000:0000, or whatever, is actually DM> over somewhere else. The DOS session never knows. ;-) The OS is DM> responsible for ensuring that two DOS sessions don't both point DM> B000:0000 to the same place. Of course, P-mode systems do the same DM> protection for ALL DOS memory (the entire 640K plus UMB, EMS, XMS, DM> etc.), not just the video. The fun part comes when the DOS session DM> tries to play with ports owned by real (i.e., not real-mode) device DM> drivers. :-) (Don't worry - the protection is still available then, DM> too.) DM> So... I take it you don't want to write device drivers? ;-) No, I'll leave that to those with more time and ambition in that area... I'll stick to *using* them... :) Gerry Danen (gdanen@accessweb.com) C+Net BBS @ 403-477-9545 http://www.geocities.com/SiliconValley/Way/9823 2 years, 140 days, 15 hours, 52 minutes, and 0 seconds until January 1, 2000. ... I'm in 386 enchanted mode. --- Maximus 3.01 * Origin: C+Net BBS. Programming & Networking. (1:342/1017) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECI00009 Date: 08/13/97 From: HERBERT BUSHONG Time: 09:17am \/To: JERRY COFFIN (Read 3 times) Subj: fstream identifying mode ::> HB> Is there a way to identify the mode that an fstream was opened in? ::> HB> (binary vs. text -- borland 4.5) ::> None of which I'm aware, but fortunately, it shouldn't be terribly ::> difficult to add the capability yourself: ::> class my_stream : public fstream { ::> int mode_; I don't know if there's a way to use it, but the filebuf class already has a mode member (protected:) which stores this information. Still, deriving a new class similar to the above seems a safer/easier way to capture the parameter... ::> You may have to add a few more things to this; for example, I believe ::> Borland supports a third parameter that determines the sharing allowed ::> with the file, and you may want to support that as well. Likewise, you Yeah, it has an optional 3rd protmode parameter, which I've never used :) Thanks, # Herbert Bushong harchon@centuryinter.net [TEAM OS/2] - Blackbeard's BBS Intelec: 239:600/0 + Fido: 1:19/19 http://www.intelec.com/software/ --- RM 1.31 2508 Is a castrated pig disgruntled? * Origin: Blackbeard's BBS - Ville Platte, LA - 318-468-3385 (1:19/19) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECI00010 Date: 08/13/97 From: HERBERT BUSHONG Time: 09:17am \/To: DANIEL JONES (Read 3 times) Subj: WATCOM and C++ ::> LM> hey!, ive got WATCOM V11.0, and wondering how do you do si ::> LM> assembly, without the use of confusing pragma's a stuff?? ::> LM> i mean, is it possible todo it like borlands C?, ie asm; { lalalalal ::> Nope. #pragma's is how Watcom implements inline assembly. I'll agree Watcom 11.0 supports the _asm {} method of inline assembly. # Herbert Bushong harchon@centuryinter.net [TEAM OS/2] - Blackbeard's BBS Intelec: 239:600/0 + Fido: 1:19/19 http://www.intelec.com/software/ --- RM 1.31 2508 URA Redneck if you have grease under your toenails * Origin: Blackbeard's BBS - Ville Platte, LA - 318-468-3385 (1:19/19) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECI00011 Date: 08/13/97 From: LARRY RINK Time: 07:14pm \/To: LESLIE SATENSTEIN (Read 3 times) Subj: Apl LR> Anyone who knows a programming language called A.P.L. or LR> Dyalog or Dyalog Prefect, please netmail me at LS> Hello Larry, LS> I used to be an APL guru. Did it for 5 years. A super great LS> interpreted language. Can you be reached via NETMAIL at 1:167/133 ? Or do you have access to a Fidonet echo called INTERUSER? (it's open forum and we could chat there). Larry Rink Sysop The Goat's Pen BBS --- Maximus 3.01 * Origin: THE GOAT'S PEN 414/820-9092 Sussex, Wi. U.S.A. (1:154/500) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECJ00000 Date: 08/14/97 From: DANIEL JONES Time: 05:06am \/To: JERRY COFFIN (Read 3 times) Subj: Sunir ventures into C++ re: writing cout << "Number = " << Number << endl; without references. JC> DJ> I'm not aware of a way to concatenate JC> DJ> operators like this via a pointer to a class. Could you demonst JC> No need for pointers. You can use actual objects... So you could! I was so focused on the pointers vs references issue I failed to look at the broader picture. Still, the ability to return a reference to an object rather than creating and destroying multiple objects demonstrates my point that references are more than "syntactic sugar." JC> DJ> I'm really curious as to why this is easy and output is JC> DJ> straightforward. What am I missing here? JC> You're missing the fact that the input operator has to modify its JC> argument to do any good. If you had something like: JC> istream istream::operator(int x) { JC> // body JC> } JC> it'd be able to modify its copy of `x' on the stack, but couldn't do JC> _anything_ to the user's original object `x'. Meaning that the programmer would have to pass a pointer rather than the object itself - something like: cin << &Number; vice cin << Number; Regards, Daniel ddjones@pinn.net --- RM 1.31 1604 Golf balls? Is that anything like tennis elbow? * Origin: Selective Source Virginia Beach, VA (757)471-6776 (1:275/102)