--------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECQ00021 Date: 08/20/97 From: CHRIS DOWNS Time: 08:06pm \/To: MICHAEL TOTH (Read 3 times) Subj: Re: files MT> Can someone please tell me the best way to open a file (shared) is MT> c++ I am using fsopen and then attaching that to a c++ fstream.. You could just open the thing as an fstream and supply the appropriate parameters to the open call (or in the constructor call). For example: fstream f; f.open("filename", ios::binary, filebuf::sh_read); --- Blue Wave/QWK v2.12 * Origin: St. Louis Users Group (1:100/4) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECQ00022 Date: 08/20/97 From: CHRIS DOWNS Time: 08:06pm \/To: HERBERT BUSHONG (Read 3 times) Subj: Re: friends not friends : HB> My understanding was that "friend class ..." made ALL members HB> irregardless of protection "accessible" to the friend class. I've had HB> this problem before, and the only solution was to make the necessary HB> members public; but I don't really want them public. HB> friend functions work perfectly, but trying to make a whole class a HB> friend doesn't. :( HB> Any solutions? (besides deriving the *Str classes from LapTimer, I've HB> considered it but it adds some additional headaches I'd rather not HB> deal with at present) The code you provided compiles just fine on VC++ (changing the Timer_t class designation to something that's defined). And yes, your friend classes ought to be able to access private and protected members of the class for which it is a friend. It seems like you're up the creek sans the proverbial paddle... --- Blue Wave/QWK v2.12 * Origin: St. Louis Users Group (1:100/4) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECQ00023 Date: 08/20/97 From: DARIN MCBRIDE Time: 07:25pm \/To: CHRIS DOWNS (Read 3 times) Subj: replies here ->[] -=> Quoting Chris Downs to Benjamin L Mcgee BLM> I'd like the opinion of the folks in this echo concerning the BLM> following statement from the book "Black Belt C++..." CD> I though it was a good book. Eckel is a good writer and a good CD> editor! His book, "Thinging in C++" is also good. He probably also wrote "Thinging in the rain." :-) ... "Transporter chief Downs, beam the landing party to the bridge" --- FastEcho 1.46 * Origin: House of Fire BBS - Toronto - (416)601-0085 - v.34 (1:250/536) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECQ00024 Date: 08/21/97 From: CLIFF RHODES Time: 10:33am \/To: JAVIER KOHEN (Read 3 times) Subj: inline const; --> Javier Kohen wrote to Cliff Rhodes <-- JK>Why would BC++ 4.51 sometimes compile inline int JK>SomeClass:someFunc(void) const; fine, but the linker won't JK>find the "symbol". CR> Is the definition of someFunc() visible to all modules that CR> call it? IE, is it in a header file? Not just a declaration, a CR> definition. JK>enum Boolean { JK> False, True JK>}; JK> JK>class Mouse { JK> JK>[..] JK> JK>public: JK> JK>[..] JK> JK> /* This should be "inline Boolean installed() const;". */ JK> Boolean installed() const; It won't be inline unless you define it here inside the class OR you define it outside the class but still inside the header. JK>[..] JK>}; // Define the inline function outside the class inline Boolean Mouse::installed(void) const { /* ... */ } PS: You should also use the C++ bool type with true and false! Cliff Rhodes cliff.rhodes@juge.com crhodes@flash.net X CMPQwk 1.42 1692 X"Cruel is the strife of brothers." - Aristotle --- Maximus/2 3.01 * Origin: COMM Port OS/2 juge.com 204.89.247.1 (281) 980-9671 (1:106/2000) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECQ00025 Date: 08/20/97 From: JERRY COFFIN Time: 10:53pm \/To: DARIN MCBRIDE (Read 3 times) Subj: volatile objects? On (18 Aug 97) Darin Mcbride wrote to Jerry Coffin... DM> I'm trying, mostly for the sake of learning, to write a simple DM> multi-threaded comm class. Most of it seems to work, so far, except DM> the queues. I'd like to have a write queue and read queue. That DM> seems simple - there's a deque in the STL. ...or maybe not so simple -- quite a few versions of STL aren't safe for multithreaded use. I've been working on making the version that came with VC++ 4.2 completely thread-safe, and though I'm not done yet, it's the only one I've personally seen that was even close. Is your class driving the hardware directly, or does it work through a device driver? (E.g. under OS/2) DM> Except that it doesn't really want to work if I make it volatile. DM> If it is volatile, the compiler complains. Three things: what version of STL are you using, what compiler are you using, and what are the errors you get? DM> If it isn't volatile, it becomes really funny - I write to the DM> serial port fine, but reading doesn't always seem to work... if I DM> don't give it a long enough delay, the "AT" coming back from the DM> modem (which I see in a line monitor) only is discovered if I give DM> it a long enough timeout. I'm sure volatile would help here - if I DM> could figure out what I was doing with it. :-) That might depend. Assuming that you're working with a device driver for the serial port rather than driving the hardware directly yourself the data may be sitting in the device driver's queue for a while. If you're driving the hardware directly yourself, it's less clear what's likely to be happening -- have you done any debugging to figure out how long it's taking for your ISR to see the incoming data after the line monitor sees it? DM> Leaving it non-volatile and then removing the thread/queue for reading DM> may work. If you don't have _some_ queueing (either in the device driver, or your driver, if you're driving the hardware directly) you're almost certain to lose characters if you don't have a queue on the input. DM> However, I'm suspicious that the write queue may not work DM> in stress situations (i.e., trying to send a file). Writing is generally less difficult than reading, unless you work with a file transfer protocol that has a timeout. Otherwise the worst that can generally happen is that you reduce the throughput of the port. Reading is different: once a character comes in the port, you need to read it before the next character arrives, or it'll be destroyed. If you're working with a UART that has FIFOs of its own (e.g. 16550), you get a little reprieve because you don't have to handle every character immediately. However, the same general rule holds true: if you don't read characters quickly enough, you'll end up completely losing characters. 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: ECR00000 Date: 08/20/97 From: THOMAS HABETS Time: 03:40pm \/To: JEAN PILON (Read 3 times) Subj: compiler JP> what the best compiler of c++ ?? GNU C++. DJGPP for those running DOS and LCC (?) for Win32. --- * Origin: "Resistance is futile" - Microsoft (2:201/293.22) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECR00001 Date: 08/20/97 From: LEIGH MORRESI Time: 11:24pm \/To: ALL (Read 3 times) Subj: are you really sure about __ASM- watcom 23:24:0008/20/97 '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ::> HB> Look in the online help. a quick search for _asm should show youhow. ::> HB> _asm { lalala }; It's there. I searched the Help Index for asm and came up with it. _asm { ...some assembly statements }; They added it to be more "compatible" with Microsoft. The old #pragma method is still valid but this alternative is available. Ive got Watcom v11.0.. its not there!..... sorry herbert... --- 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: ECR00002 Date: 08/19/97 From: FRANK ADAM Time: 06:45am \/To: CLIFF RHODES (Read 3 times) Subj: ctors On Aug 16 11:14, 1997, Cliff Rhodes of 1:106/2000 wrote: G'day Cliff, BL>>Is this to much.. BL>>manifest::manifest(){ BL>> filename = new char[FILENAME_MAX]; BL>> while (!select(filename, FILENAME_MAX - 1)); BL>> mstreamp = new ifstream(filename); BL>>} Sometimes i want to initialize a number of variables in the constructor, in that case i normally have a public variable( call it initsuccess). This way the class can refuse all consequent calls with a single if() if the init failed on any item. Don't know how artistic that aproach is, but it works fine for me. :-) CR> Not necessarily although it does pose some problems with error CR> handling (which you could do with exceptions). Your options are to I've been thinking about this for a while, is there a technical reason why constructors are not able to return a value ? Regards, Frank --- Msged 4.00 * Origin: The ticking point, Melbourne, Australia. (3:635/728.21) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECR00003 Date: 08/21/97 From: LESLIE SATENSTEIN Time: 07:13pm \/To: LARRY RINK (Read 3 times) Subj: Apl Hello Larry, I am on the internet at leslie@contact.net I programmed APL for many a year, and did wonderful things with it. My APL was based on IPSHARPS's then IBM's. Used shared variables too. Don't have much to do with APL now, for about 10 years. I still remember much of it though. Again, contact me at leslie@contact.net Leslie Satenstein --- Maximus/2 3.01 * Origin: Juxtaposition BBS. Lasalle, Quebec, Canada (1:167/133) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECR00004 Date: 08/12/97 From: LESLIE SATENSTEIN Time: 09:36pm \/To: BOB STOUT (Read 3 times) Subj: Zortech compiler.... In a previous message concerning " Zortech compiler.... ", Bob Stout said..... BS> Zortech was bought out by Symantec. Any Zortech code you have should BS> compile with little or no difficulty using the current BS> Symantec C++ compiler. I use Zortech C++ all the time as BS> my DOS C compiler of choice. While it's a great C BS> compiler, it has long since been eclipsed as a C++ compiler BS> by other vendors. Hello Bob, I have lost contact with Walter Bright. Can you update me on his whereabouts? Leslie Satenstein 97/08/04 ___ X KWQ/2 1.2i X If I were here more often, I wouldn't be gone so much. --- Maximus/2 3.01 * Origin: Juxtaposition BBS. Lasalle, Quebec, Canada (1:167/133)