TIP: Click on subject to list as thread! ANSI
echo: c_plusplus
to: GERRY DANEN
from: DARIN MCBRIDE
date: 1997-08-10 08:09:00
subject: C++ or ASM?

 -=> Quoting Gerry Danen to Darin Mcbride
 DM> Nope.  The const_cast is _removing_ const (since there isn't a const
 DM> in the "brackets" ()).  The static_cast is doing nothing about
 DM> static - it's saying that we're not going to do a runtime check, but a
 DM> compile time check to change the volatile void* to volatile char*.
 GD> I've never used volatile on any direct screen I/O.  Perhaps that's
 GD> because under single-tasking DOS that's not a problem.  In what way
 GD> would I see problems under multi-tasking OS like WinNT or OS/2?
Something tells me you just wanted the answer to the other question, but had
to keep it on topic.  That's ok - I'm not the moderator, and thus the
moderator isn't so anal that he'd care.  :-)  [There's an implication in
there somewhere... ]
Anyway, you would use volatile under DOS for global variables that are
modified by interrupts, or anything else modified by interrupts for that
matter.
For example, if you had an interrupt that changed a global stack to add each
new character that came in from a modem, anything dealing with the stack
would have to be considered volatile (in OS/2 or NT, you would use semaphores
to guarantee the variable didn't change between accesses).  Another one would
be, say a pointer to the incoming byte of a serial port - this would be
volatile as well.
OS/2 and WinNT have semaphores that render volatile mostly useless.  Only
your own process threads can modify your variables, and all these variables
can be protected by semaphores.  If they aren't so protected, you run into
race conditions that can make the system blow up.  ;-)
Same for DOS, but you don't have as much power over it, so you use the
volatile.
(The screen isn't going to change, so having a volatile pointer to it is
useless... unless you have an interrupt handler also modifying it.)
 GD> BTW, you got internet e-mail and/or fido node yet?
Internet: dmcbride@ibm.net
Fido:     Keep an eye on the nodelist.  I'll have my BBS line this Friday and
apply for Fido shortly thereafter.  So I should have a Fido node number
within two weeks.  And then I'll be posting from my own system shortly after
that.  :-)
... Programmers don't get sniffles, they get a CODE.
--- FastEcho 1.46
---------------
* Origin: House of Fire BBS - Toronto - (416)601-0085 - v.34 (1:250/536)

SOURCE: echomail via exec-pc

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.