--------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECY00015 Date: 08/28/97 From: JERRY COFFIN Time: 04:09pm \/To: DARIN MCBRIDE (Read 2 times) Subj: volatile objects? On (24 Aug 97) Darin Mcbride wrote to Jerry Coffin... JC> ...or maybe not so simple -- quite a few versions of STL aren't JC> safe for multithreaded use. I've been working on making the JC> version that came with VC++ 4.2 completely thread-safe, and though JC> I'm not done yet, it's the only one I've personally seen that was JC> even close. DM> Hmmmm... true. What do you do to make it "thread-safe"? Any DM> semaphoring, or just the volatile, letting the user do the semaphores? Well, I'm actually using critical sections instead of semaphores, but the idea's the same, just critical sections are much lower overhead in Win32. In Win32, semapores and mutexes are kernel objects manipulated only by kernel code, where critical sections are process-specific and are manipulated entirely in user-mode. DM> Now that you mention it, someone was advertising about having a DM> thread-safe version of STL available... let's see if I can find the DM> message... SGI says it's on: http://www.sgi.com/Technology/STL. Actually, I've got a copy of that that was supposedly adapted to VC++ on Win32, but I haven't been able to get it to work for me. DM> Device driver, of course. :-) This'd be a bigger mess if I were DM> forced to do this under DOS. Mind you, between the two of us, I'd DM> say we'd have a hard time giving half a darn about DOS - and that's DM> assuming you give a full darn about DOS! ;-) Me care about DOS? Yes, I actually do care about DOS deeply, in much the way I care deeply about mid-east terrorism. I wish they'd both just go away and let the rest of us live in peace. JC> Three things: what version of STL are you using, what compiler JC> are you using, and what are the errors you get? DM> GCC. That should about explain it. ;-) Maybe... DM> The errors are asking me to find a type::func(...) volatile function DM> which, obviously, doesn't exist when my variable of type "type" is DM> volatile. i.e.: DM> volatile queue > IOQueue; DM> IOQueue.push('c'); // no queue >::push(char) volatile! DM> So, at the least, I expect that volatile functions are required... Sounds about right. JC> That might depend. Assuming that you're working with a device JC> driver for the serial port rather than driving the hardware JC> directly yourself the data may be sitting in the device driver's JC> queue for a while. DM> Yeah, that was it - I found that one a few hours later. Had to drop DM> my read to 1 character at a time unless I know there is more waiting. Hmmm...can't you set a time-out on reading from the serial ports? I never did much with serial ports under OS/2, but I _thought_ I remembered being able to set the timeout with DosDevIOCtl or somesuch. DM> As I said, I use the device driver. I know SIO has a 4k buffer for DM> each com port - although I'm unsure if it dynamically "splits" to DM> whatever is needed for each buffer, or if that's 4k for each read DM> and write queue on each port. Offhand, I'm not at all sure, though if memory serves, you can also adjust the size in config.sys. (Or has OS/2 renamed that - I think it was config.sys the last time I looked though...) JC> Writing is generally less difficult than reading, unless you work JC> with a file transfer protocol that has a timeout. Otherwise the JC> worst that can generally happen is that you reduce the throughput JC> of the port. DM> This would generally be a bad thing, too. ;-) Yes and no. If you miss reading even a single character while doing something like a binary file transfer without an error-checking protocol, you have a real problem. Even missing one character in a million by a millisecond or so means your file transfers are always highly suspect. By contrast, if you miss writing one character in a million by a millisecond or so, the drop in throughput is far too small for most people to care about. DM> Which is why I wanted the "infinite" read buffers. The proble here is that in creating an "infinite" read buffer, you're likely to end up doing dynamic allocation. Unfortunately, the allocation itself is likely to take long enough that you could well end up losing characters while you do it unless you use flow control to stop the input while you do the allocation. DM> I've got my own queue class that is thread-safe (I think), complete DM> with semaphores. (Well, semaphore. One per object.) It seems to DM> work so far. That's always a good sign, but not always an assurance of correctness when you're doing multithreading. I had some multithreaded code that worked beautifully for years, but crashed almost _instantly_ the first time I had it on a multiprocessor machine. As always, testing can assure you that bugs are present, but can never assure you that they're not... DM> The one thing I dislike somewhat is that I'm going to have to make DM> my events public... so that the caller can use multiple-wait (mux) DM> calls to wait on read, write, and, say, a keyboard thread, or any DM> other thread. I could "demand" (via interface restrictions) that DM> the user of this class was its own thread, but threads have costs, DM> too... ah well, the joys of design. :-) Yup, it's definitely a pain. Another possibility I've considered is a class for doing the waiting on various events, and make it a friend of the class(es) that use events internally, as well as having conversions from the native OS event data structures. This was you still restrict the visibility of the event(s) in your class to one specific place rather than the whole world. On the down side, it still implies tight coupling between the event class and the other classes that use events internally. 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: ECY00016 Date: 08/28/97 From: JERRY COFFIN Time: 04:31pm \/To: DARIN MCBRIDE (Read 2 times) Subj: volatile objects? On (25 Aug 97) Darin Mcbride wrote to Jerry Coffin... DM> I'm unsure if you realize it, but events and semaphores are DM> significantly different... :-) Actually, I am...now. When I first wrote the code, I wasn't, and by the time I realized my error, it would have been a pain to change. DM> So, is this a "go ahead and post your thread-safe [?] OS/2-based DM> templated circular queue"? :-) Something like that, yeah. DM> (Win32 could likely get away with just using Critical Sections, but DM> some of the Semaphore class could only be replicated via undocumented DM> peeking into the CRITICALSEMAPHORE[?] structure since there is no DM> other way that I saw to determine who currently owns the semaphore. Hmm...It's a CRITICAL_SECTION for a critical section, or a HANDLE for a semaphore. However, I'm interested in knowing why you want to know about the owner of either. Nearl anything you try to do with that information is going to be subject to race conditions... 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: ECY00017 Date: 08/28/97 From: JERRY COFFIN Time: 03:53pm \/To: NEIL HELLER (Read 2 times) Subj: Why the braces? On (23 Aug 97) Neil Heller wrote to All... NH> I always thought that one of the features of C++ is that variables can NH> be declared ANYWHERE (such as near where you're going to use them). That's pretty nearly true, but not quite... NH> However I ran across a situation in MSVC 1.6 with a CPP module that NH> seems to contradict this. Can someone explain to me why? MSVC 1.6? I assume that was a typo and you meant 1.5? NH> If I write a switch statement thusly, I get compiler errors: NH> switch (foo) { NH> case 1 : NH> int bar = 2; NH> break; NH> case 2 : NH> int bar = 3; NH> break; NH> } Yup, you should. When/if you jump past initialization of a variable, you should get an error. You've also defined the same variable twice in the same scope, which is an error as well. There was a lot of debate as to what the "right thing" to do was when you jumped past the initialization of a variable. One camp said that initialization was part of creating the variable, so the initialization had to take place. The other camp said that you were jumping past the code, so the code to initialize the variable shouldn't execute. Eventually both camps agreed that no matter which way you went, you had a problem, and they made the whole thing illegal. NH> However, if I write the code this way there are no errors: NH> switch (foo) { NH> case 1 : { NH> int bar = 2; NH> break; NH> } NH> case 2 : { NH> int bar = 3; NH> break; NH> } NH> } Here you're doing two things. First of all, with the braces present, you've got two separate variables that both happen to be named `bar', but which are in separate scopes, so that's reasoanble. Second, when the switch statement jumps to label 2, the initialization of the first bar isn't an issue - the scope it's in is never entered, so it's clear that it should never be created or initialized. This isn't nearly as difficult to handle with variables of type int, but consider the following: class number { int a_number; public: operator int() { return a_number; } number(int init) { cout << init << endl; } ~number(int init) { cout << "number dies" << endl; } }; switch (foo) { case 1: number x(3); break; case 2: cout << int(x) << end; break; } Now what should happen when foo==2? Should the ctor for `x' run twice with two different values? If we just used `x' in the second case instead of defining it, should we be able to depend upon it having been initialized to 3? Ultimately, it was decided that it was best to just make the whole thing illegal. 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: ECY00018 Date: 08/28/97 From: FRANK MASINGILL Time: 03:45pm \/To: CLIFF RHODES (Read 2 times) Subj: Calculator 15:45:4808/28/97 CR> Frank, you haven't messaged back about the last version of the CR> calculator. I was hoping you'd have some questions or CR> comments. CR> One area where it was still weak is in the input. The user CR> could input a value that might be bad. This could lead to some CR> problems. I have modified the program again to fix this. I CR> added a function getint() CR> After this I think it is in pretty good shape--for a C CR> program. It is now time to do a conversion to C++, if you want CR> to. The first thing to CR> the objects involved? How do the objects interact? Those are CR> the sort of questions to answer. If you want to work through CR> this a step at a time, post a message with your view of the CR> objects involved. You'll find you have to look at the problem CR> in a way different from C. (followed by your code) Cliff, what I am all of a sudden suffering with great pleasure, here, is an "embarrassment of riches." You led the field in a rush to help me which has, luckily for me, become something of an avalanche and believe me I'm struggling as hard as I can to encompass everything. You may rest assurred that I have no intention of letting any of your instructions be wasted I'll be posting just as soon as I can get some principles CLEARLY in mind. Please accept my tremendous gratitude and expect me back as soon as I have something to ask further about. You guys have really showered me with help and I wonder that I waited so long to post something and ask for help. I'm still dealing with all of it, believe me. Checked out another C++ book from the library even today to add to ones I've purchased. Blessed be Fidonet!! Sincerely, Frank --- PPoint 2.03 * Origin: Maybe in 5,000 years - frankmas@juno.com (1:396/45.12) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECY00019 Date: 08/26/97 From: NEIL HELLER Time: 07:08pm \/To: CHRIS DOWNS (Read 2 times) Subj: PRINTING POINTER VALU CD> void foobar(int type, long additional_info_of_some_type); CD> If you want to call foobar() with a CString, the cast to the LP(C)STR CD> does a type conversion and the cast to the long is to satisfy the CD> semantics of the function you want to call. I'm not trying to be a smart-ass believe me; what I assume of that function is that if "type" is a particular value, you'll cast the long back into a far pointer and dereferrence the pointer in order to get at the string. Correct? * 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: ECY00020 Date: 08/28/97 From: HERBERT BUSHONG Time: 10:53am \/To: CHRIS DOWNS (Read 2 times) Subj: friends not friends ::> ::> It seems like you're up the creek sans the proverbial paddle... ::> HB> Nah, I just consolidated, and made the orginal class derived from ::> HB> fstream as well, moved the functionality of the other 2 to it, and o ::> HB> rid of the excess baggage of the other 2 stream classes... ::> Darn if that necessity deal isn't one mother of a mother..... You said a mouthful there! :) In this case, I wouldn't call her a mother, but Royal Queen B.... # 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 Kamikaze Pilot Wanted: Experienced only need apply. * Origin: Blackbeard's BBS - Ville Platte, LA - 318-468-3385 (1:19/19) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECY00021 Date: 08/27/97 From: ROGER SEN MONTERO Time: 01:25am \/To: DARIN MCBRIDE (Read 2 times) Subj: volatile objects? Hola Darin! 22 Aug 97 07:31, Darin Mcbride wrote to Thomas Maeder: TM>> How do you make it volatile, and how does the compiler complain? DM> On the marked line (!!!), the compiler complains that it cannot find DM> a function "queue >::push(char) volatile". The function, DM> without volatile, exists, though. STL (specially HP's one) has a lot of problems with multi-threading. SGI's STL is much better, but it was not designed with multi-threaded concepts in mind. Recently there was some posts in comp.c++.std about multi-threaded STL (and some companion files, including bstring.h) I have to do some tests with multi-threading issues and STL (probably using OS/2) so I'll post a message as soon as I finish them. Moreover, you cannot push chars in a queue >. You should push deques of chars. Saludos. Roger. - rogersm@bbs-ce.uab.es ... Without the letter U, units would be nits. --- Squish/386 v1.11 * Origin: Pro-Line BBS - Nuevo Telefono: (93) 442-7950 (2:343/106) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECY00022 Date: 08/28/97 From: THOMAS MAEDER Time: 07:44pm \/To: BALOG PAL (Read 2 times) Subj: Overloading NEW & DELETE BP> CR> If you are overloading the global new operator, you won't be ab BP> CR> get the 'original' global new. BP> Why? Overloading never removes an existing function. You can define BP> new() functions that take different number and/or type of arguments, BP> will still have the original new. Both of you are right. Cliff meant "If you provide your own implementation of the global new operator...". In that case, the 'default' implementation can't be accessed. If you overload it, the case is different of course. Thomas --- MM 1.0 #0113 Everyone hates me because I'm paranoid. * Origin: McMeier & Son BBS (2:301/138) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECZ00000 Date: 08/29/97 From: DARIN MCBRIDE Time: 06:11pm \/To: COYOTE (Read 2 times) Subj: DJGPP with C++ add-on -=> Quoting Coyote to All Co> Hi ppl, i'm kinda new with C++ but there is something i'm having Co> problems with. I am using DJGPP with C++ (add-on or something) and Co> wehn i try to compile something a with it, (a c++ file) it as an Co> error. I'll write the source and all i write .... Co> Ok this is the source file. Its named CAR.CPP : Co> #include "car.hpp" //CAR.HPP IS IN THE SAME DIRECTORY [rest of car.cpp deleted] Co> To compile it i go in the car.cpp directory and write: Co> C:\PATH>gcc car.cpp -o car.o //THEN IT WRITES THE STUFF UNDER If you just want to make an object file, gcc requires a '-c' flag: gcc -c car.cpp -o car.o I usually just use gcc -c .cc ... it defaults to an output of *.o for -c compiles, and *.exe for full compiles when you only have one source file. Co> c:/djgpp/lib\crt0.o(.data+0x92):crt0.s: undefined reference to `main' It's trying to do a full compile. Good luck! ... He who lives by the sword would probably get arrested. --- FastEcho 1.46 * Origin: House of Fire BBS - Toronto - (416)601-0085 - v.34 (1:250/536) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ECZ00001 Date: 08/28/97 From: MANISH MALIK Time: 03:46pm \/To: TARUN SINGH (Read 2 times) Subj: Re: Just a test mail ==> Remembering what Tarun Singh said to All <== TS> Please Ignore this is just a test mail NO NO NO ! I am NOT ignoring it ! *=======================================================================* | MANISH MALIK manish@dolbbs.com Fido: 6:606/26 | |=======================================================================| | manish.malik@47.indiagate.com Fido: 6:606/47 | *=======================================================================* ... VANDE MATRAM. Respect thou motherland. Independent INDIA turns 50 ! --- Maximus 3.01 * Origin: Delhi Online <5578535/36> -=[New Delhi/India]=- (6:606/26)