On (04 Apr 97) Darin McBride wrote to Jerry Coffin...
 DM> Perhaps adding RTTI support to ensure we ARE 
 DM> dealing with a ThreadBase pointer here... :-)
 JC> It can't be done: you can't use RTTI on a pointer to void.  RTTI
 JC> has the same problem you do at that point: it doesn't know enough
 JC> about the pointer to find out anything.
 DM> I thought that RTTI _could_ do this for pointers to void.  Perhaps
 DM> not, though...  It's been a while since I've had access to semi-decent
 DM> manuals to RTTI support.  Right now, I only have GCC that supports it,
 DM> and at that very loosely.  And the documentation for GCC's C++ support
 DM> is, well, for all practical purposes, not there.  Watcom 10.6 doesn't
 DM> have anything on it that I can find.  :-/  Borland/2 1.5?  Let's not
 DM> even go there.  :-)
Some looking in the standard shows that I was dead wrong.  You should be
able to use a dynamic_cast to do the job.  I'm still not sure how the
compiler can ensure that it'll work, but I guess that's its problem.
 JC> Under Win32, most, if not all, of this involves the thread handle
 JC> instead of the ID.
 DM> Ah.  I'm not sure why Win32 added that... I doubt OS/2 1.3 had it
 DM> (since removing support would break programs, something IBM has
 DM> committed to not doing).  And thus Win32 must support doing this
 DM> stuff with the original 16-bit OS/2 calls (killing threads was
 DM> added in OS/2 3, so that's not an item to worry about) using only
 DM> the thread ID.
Not really.  NT supports the OS/2 1.x API, but not as part of Win32 -
it's a separate subsystem of its own.  The Win32 and OS/2 subsystems
each make calls to the NT kernel to create threads, set their
priorities, etc.  However, the interface they provide is entirely up to
them.  Looking through the NT DDK documentation it looks like thread IDs
are _purely_ part of the interface they provide - the NT kernel calls
dealing with threads have noting to do with thread IDs at all.
I'm guessing here, but it looks like in the OS/2 subsystem, a thread ID
is probably just an index into an array of thread handles.  When you
carry out an operation on a thread, the subsystem just looks up the
thread handle, then makes kernel calls to manipulate that handle.
The same general technique can be useful in C++ at times.  Assume you
have a class that manipulates some data on behalf of some client code.
The same instance of the class might manipulate different pieces of data
for different parts of the client code.
Therefore, you want each piece of client code to be able to identify its
own piece of data.  However, you _don't_ generally want to give the
client code a pointer to the data.  One method is to simply cast the
pointer to a pointer to void so the client can't dereference it.
However, if the client gets sneaky, they can still play games with it
we'd rather they couldn't.
As an alternative, can simply create an array of pointers in the class,
and pass the client code an index into that array.  The array itself
remains completely private, so the client code has not access to it at
all.
    Later,
    Jerry.
... The Universe is a figment of its own imagination.
--- PPoint 1.90
---------------