Re:New C++ experimental feature: The tadpole operators
by asveikau on Tuesday May 26, 2015 @03:03PM
(#9606903)
> By comparison, a 'handle' in Windows is a "memory block the contents of which you don't know what they are".
This is incorrect.
In Windows, the HANDLE is a typedef for a void pointer, but its usage is usually 100% analogous to a file descriptor - i.e. it is a token passed to kernel space, where the kernel looks it up in a per-process table of open files. I say "usually" because some components have re-used the HANDLE typedef for things which are not kernel objects - for example the HANDLE that comes from FindFirstFile() is actually a pointer to a structure in user-space [which AFAIK itself has a HANDLE to the directory].
Re:New C++ experimental feature: The tadpole operators
by ms2 on Wednesday May 27, 2015 @08:49AM
(#9610947)
That's true for some handles in Win32, but (since we're talking about classic MacOS) Win16 handles were usually NEAR pointers inside kernel segments.
Re:New C++ experimental feature: The tadpole operators
by JoeAltmaier on Wednesday May 27, 2015 @08:51AM
(#9610955)
True! That was a disaster; only 64K (16 bits) handles were possible across all processes. Many APIs had to be deprecated and redesigned when it went 32-bit.
I've argued for using uuids for handles from here on out. They are endless; no effort to coordinate handle spaces is ever needed; they work locally and on the network; on some architectures they are even a register width scalar.
Re:New C++ experimental feature: The tadpole operators
by rcalhoun on Monday June 01, 2015 @04:42PM
(#9641997)
That should be "sprong" not "sproing". I restored Maf Vosburgh's page here: http://textmail.net/sprong/sprong.html
This meant that when accessing data through these handles, you had to write code like this:
or Eventually, someone coined a pseudo-operator for reaching fields from a handle without requiring parentheses: [0]-> was named the "sproing" operator (on the theory that it indicates the desired value popping out of a box).