--------------------------------END HERE--------------------------- 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: ED400001 Date: 09/02/97 From: JERRY COFFIN Time: 09:52am \/To: FRANK ADAM (Read 2 times) Subj: ctors On (28 Aug 97) Frank Adam wrote to Jerry Coffin... JC> To manage this, you'd have to invent some _entirely_ new syntax JC> and semantics that don't bear even minimal resemblence to anything JC> in C. FA> I believe it should've been done. After all C++ is not C and classes FA> are unique to the former. It's very possible that by default a class FA> may be initialized similarly to a structure,but once a user defined FA> ctor is used it becomes a definite (be it implicit) function call. It's true that classes are unique to C++. However, they're conceptually quite closely related to structs in C. In fact, the only fundamental difference is that C says you can't put a function in a struct. C++ simply eliminates that restriction. In C++, `class' is simply an alias for: `struct { private:' -- i.e. it declares a struct in which members are private by default. FA> IMHO, all of a sudden the syntax FA> just disallowed the checking of a return value from a function. The syntax `void funcname()' did that in C a long time ago. Much like a function declared to return void, a ctor simply doesn't HAVE a return value, so nothing ever disallowed checking the return value. JC> E.g. you could invent a method of returning two entirely separate JC> int status; JC> someClass *object; JC> status, object = new someClass; FA> Or could've been.. FA> int status; FA> someClass *object; FA> object = new someClass(&status); FA> someClass x(&status); FA> Of course there would be no "no arg" constructors. And there'd be no way to use this in conversion ctors, etc. either. The ultimate goal for classes in C++ was/is the ability to create a type that can be used similarly to a type built into the language. While I wouldn't say this was realized completely, I don't think the methods eitehr you or I suggested allow that to nearly the degree that exception handling does. FA> Anyway i was just thinking aloud, i don't think compiler vendors upon FA> reading this, would rush off to change the language just for me.:-) Improvements are rarely finished the minute somebody first starts to discuss them. I'm not _at_ _all_ averse to discussing things just becaue they're not finished and polished. As I point out above, I don't think either you or I have come up with a method that's currently superior to exception handling. However, that doesn't mean that such a thing might not exist. Even if you or I decide it really doesn't exist, the discussion leading to that conclusion might well be valuable anyway. 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: ED400002 Date: 09/02/97 From: JERRY COFFIN Time: 01:17pm \/To: MATHIEU BOUCHARD (Read 2 times) Subj: MATHPLAY.CPP On (28 Aug 97) Mathieu Bouchard wrote to Frank Swarbrick... MB> hey... when i was in 6th grade, i made a similar program, but a MB> MultiMedia version. used CGA graphics using DRAW, PAINT, CIRCLE and MB> high-quality music using PLAY on the PC Sqweaker in square wave mode. ^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^ It's a god thing you threw that in - without the humor, talking about writing BASIC wouldn't be topical. 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: ED400003 Date: 09/02/97 From: JERRY COFFIN Time: 10:05am \/To: DARIN MCBRIDE (Read 2 times) Subj: volatile objects? On (31 Aug 97) Darin Mcbride wrote to Jerry Coffin... JC> Actually, I am...now. When I first wrote the code, I wasn't, and JC> by the time I realized my error, it would have been a pain to JC> change. DM> Hmmm... when I looked at the code, it didn't look too bad to switch... DM> mind you, I probably have a little more experience with OS/2 DM> semaphores, so it'd just look easier to me. :-) The problem wouldn't have been in changing the class itself. It would have been in changing the code that depended upon the class... DM> The actual code is an IsClaimed() function to see if the currently DM> running thread owns the semaphore. It's primarily for assertions - DM> make sure that we are currently inside our semaphore... i.e. DM> template DM> class SafeQueue DM> { DM> // ... DM> private: DM> DoPush(const T& t) DM> { DM> assert(GetSemaphore().IsClaimed()); DM> ... DM> } DM> // ... DM> }; DM> Any code calling DoPush should have already claimed the semaphore DM> before calling DoPush(). Hmm...presumably, there's a public Push() that's basically something like: Push(const T &t) { GetSemaphore().Claim(); DoPush(t); GetSemaphore().Release(); } ? Offhand, it doesn't seem like the fact that a semaphore is involved should be part of the interface. However, this leave a question in my mind as to whether it makes sense to separate obtaining the semaphore from the code that accesses the resource protected by that semaphore. I'm not sure it wouldn't be better to simly merge the two instead of trying to ensure that it has happened with an assert. DM> That is the ONLY reason I have for it. I do NOT have a "who owns DM> it?" function. If you want to know if someone else has it, try to DM> claim with a 0 timeout... but it doesn't tell who. Ah, that at least eliminates the danger of any kind of race condition. 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: ED400004 Date: 09/02/97 From: JERRY COFFIN Time: 01:18pm \/To: CHRIS DOWNS (Read 2 times) Subj: volatile objects? On (30 Aug 97) Chris Downs wrote to Darin Mcbride... DM> Mind you, GCC doesn't support default template arguments yet. CD> Does anybody? Rumor has it that there's one that does, but it's not apparently widely available yet. 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: ED400005 Date: 09/02/97 From: JERRY COFFIN Time: 11:56pm \/To: BALOG PAL (Read 2 times) Subj: volatile objects? On (30 Aug 97) Balog Pal wrote to Jerry Coffin... BP> I just ran into a problem. Is there something in WIN32 like the BP> ctirical section in DOS was? Not really. I'm assuming you mean the function that keeps DOSSHELL and/or Windows 3.x from switching to another task? BP> But isn't there a simpler method to prevent a task switch for a short BP> section in the program? I have a program that is polling directories BP> and moves the files that apper there to another directories. Another BP> program creates those files. In several places it simply uses BP> MoveFileEx itself. That shouldn't be a problem. If one process attempts to use MoveFileEx (or MoveFile) on a file while another process has the file open, the attempt at moving the file will fail. BP> I found it works in practice. Bus thinking a bit deeper I consider BP> it's not really safe that way. What if a task switch occours when the BP> system is in the middle of MoveFileEx? The OS ensures that moving the file takes place atomically, or at least appears to do so. I haven't looked at MoveFileEx in particular, but it can do some tricks to let some task switches take place during lengthy processes without problems. However, you might want to take a look at FindFirstChangeNotification or (better yet) ReadDirectoryChangesW to take care of things even more simply. It's not entirely clear what you're doing, but from the sound of things ReadDirectoryChangesW might be your best bet if you can limit your program to NT. (Even more than many of the OS/2 and UNIX fans, I can hardly wait for the day Win95 is dead and buried. IMO, restricting your program to NT is a good first step toward making it more useful and robust, but unfortunately much of the world hasn't realized this yet.) 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: ED400006 Date: 09/02/97 From: JERRY COFFIN Time: 01:19pm \/To: MATHIEU BOUCHARD (Read 2 times) Subj: Why the braces? On (28 Aug 97) Mathieu Bouchard wrote to Darin Mcbride... MB> in C/C++, lack of initialization is not an error. the error is that MB> there are two identical variable names. In C++, lack of an initializer isn't necessarily an error, but jumping past an initializer to a point at which that variable is still in scope IS an error. 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: ED400007 Date: 08/29/97 From: NICKOLAS HIRGIJ Time: 09:01am \/To: CAMERON CLARK (Read 2 times) Subj: stream bug??? ddt.demos.su!f400.n5020!f121.n461!uanet.cit-ua.net!uanet.kharkov.ua!useua!f121 .n461!f133.n461!f108.n461!not-for-mail Hello Cameron! Mon Aug 25 1997 06:50, Cameron Clark wrote to All: CC> ofstream outf("out.bin"); CC> char string[6]; CC> strcpy(string,"12345"); CC> string[strlen(string)] = '\n'; CC> outf.write(string, strlen(string)); CC> outf.close(); CC> The side effect is that it writes the following: CC> 12345#13#10 (where #13 & #10 are ascii characters) That isn't side effect. It is normal conversion ("\x10" -> "\x13\x10") for output in _TEXT_ mode, and #13#10 -> #10 for input. In otherwise, "\x10" inside = "\x13\x10" outside. Regards, Nickolas --- ⮩ , ஧ 3.00.Alpha4+ * Origin: 砩 砩... 䥩 - 䥩. (2:461/108.5) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ED400008 Date: 08/30/97 From: NICKOLAS HIRGIJ Time: 03:26pm \/To: KEVIN CAMPBELL (Read 2 times) Subj: Reset ddt.demos.su!f400.n5020!f121.n461!uanet.cit-ua.net!uanet.kharkov.ua!useua!f121 .n461!f133.n461!f108.n461!not-for-mail Hello Kevin! Sat Aug 23 1997 07:02, Kevin Campbell wrote to Viktor Osadchuk: >> asm { >> mov ax,0 >> mov es,ax >> mov ax,1234h >> mov di,0472h >> mov es:di,ax /* Error: Memory reference expected */ >> int 19h >> } KC> Put square brackets around the reference "mov [es:di],ax". KC> Kevin Campbell And what You say about next hard reset method: 1) asm{ mov AL,0FEh ; Reboot out 64h,AL ; ᮡ⢥ } or C: outp(0x64,0xFE); or (for other compilers): outportb(0x64,0xFE); 2) C only (without asm): ((void (far*)(void))*(long*)"")(); Regards, Nickolas Hirgij, Kharkov, Ukraine --- * Origin: HNI (2:461/108.5) --------------- FIDO MESSAGE AREA==> TOPIC: 203 C++ Ref: ED400009 Date: 09/02/97 From: DARIN MCBRIDE Time: 06:23pm \/To: ALBERTO MONTEIRO (Read 2 times) Subj: Roman Numeral??? (cpp) -=> Quoting Alberto Monteiro to James Norman AM> ostream& operator<<(ostream& Out, Roman& R) AM> { AM> Out << R.str; AM> return Out; AM> } You may want to hide both str and n and provide operator char* and operator int instead... AM> // AM> // Roman input AM> // AM> istream& operator>>(istream& Inpu, Roman& R) AM> { AM> char str0[50]; AM> Inpu >> str0; AM> R = Roman(str0); AM> return Inpu; AM> } What happens if you already have a Roman string created? You lose memory... try deallocating the string, first. Better yet, use the string class rather than the char* with strdup. I'm not convinced it works, but your test program tests my suspicions, so I'll just have to try it. :-> Yeah, I was worried about that. First of all, you have a str[1000] that's never used in the .cpp portion. :-) Second, a few other test cases: IL = 49 [core dumped!] IIC = 98 VC = 95 And, the slightly more obscure: IVC = 96 These are a few that you fail on. Your algorithm, I'm guessing, would have to be completely reworked to accomodate these. Especially if you want to not allow, say: IVCV ?? 101 This is why the Roman Numeral problem is difficult. Not impossible - you still follow a straight-forward methodology to come up with the "conversion" - but it's got a lot of little quirks. :-) Good luck! ... RAM = Rarely Adequate Memory --- FastEcho 1.46 * Origin: House of Fire BBS - Toronto - (416)601-0085 - v.34 (1:250/536)