In Mac programming (pre-OSX) it was common for the OS to give you memory blocks not using a pointer, but using a 'handle', which under Mac OS<=9 meant "a pointer to a pointer" (where the direct pointer was under OS control so that it could move memory blocks around in low-memory situations. By comparison, a 'handle' in Windows is a "memory block the contents of which you don't know what they are". On Mac OS<=9, you did know the contents; you just had to double-dereference your pointer to reach them)

This meant that when accessing data through these handles, you had to write code like this:

    (*handle)->field;

or

    (**handle).field;

Eventually, someone coined a pseudo-operator for reaching fields from a handle without requiring parentheses:

    handle[0]->field;  

[0]-> was named the "sproing" operator (on the theory that it indicates the desired value popping out of a box).

> 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].

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.

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.

That should be "sprong" not "sproing". I restored Maf Vosburgh's page here: http://textmail.net/sprong/sprong.html

There is the down-to pseudo-operator --> as in

    int x = 3;
    while(x --> 0) {
      std::cout<<x<<"\n";
    }

In addition to the rightward arrow, there's the leftward arrow:

    int x = 3;
    while(n <-- x) {
        cout << x << endl;
    }

which is different because it doesn't include the lower bound `n`. And of course, if typing the ">" is too taxing, the "---" operator is equivalent to the "-->" operator:

    int x = 3;
    while(x --- n) {
        cout << x << endl;
    }

A few more goodies in this style at http://steike.com/code/useless/evil-c/ (home of the zip-quine.)

A crying face is called "ever"

    #define ever (;;)

    for ever {
        // do something
    }

"clown eyes"? That's the Bugs Bunny operator!

I don't know if it's named, but there's the !!?!!? operator [1]

    !ErrorHasOccured() ??!??! HandleError();

[1] http://stackoverflow.com/questions/7825055/what-does-the-c-o...

i'd call that the bunny operator because it reminds me of the sanrio bunnies.