The term handle generally means some opaque value that has meaning only to the API which produced it. In Win32, the HANDLE type is either a pointer in kernel memory (which applications cannot access anyway) or an index into some kernel-internal array.

A handle is an old and revered concept.

A cookie is much the same thing. Or a GUID. Or a ticket to retrieve your car from a car park, or your coat from a fancy restaurant, etc.

Its any unique value that when presented back to the issuer can be used to track back to the actual thing referred, by whatever opaque mechanism the issuer wants. You may or may not know anything about that process, nor what the underlying thing is, exactly (only conceptually).

It was heavily used by Windows, but it is certainly not unique to Windows.

You would not normally use "handle" to mean "pointer to struct." Handle is more like "token" than like "pointer." It refers to something - file, system resource, memory, state-snapshot, etc. But what-exactly-it-is is based on the context of the handle itself (i.e. who issued the handle).

Handles were also used heavily in early filesystem programming in K&R C.

I use the word handle to mean a pointer that points to an "object" that represents a resource - often an OS resource, whereas a pointer just points to some memory. If you have a handle to something, you shouldn t try to read and write bytes into it directly, but manipulate it through provided methods.

Often handles are implemented as an opaque void *, which is further encouragement not to try to directly dereference it.

Since you refer to handles being used as a pointer to a structure, as used by a Windows programmer, I ll answer within that context. Please note that there are clearly many different kinds of "handles", as it is a generic concept widely used within the computing environment. Certainly you will be familiar with the concept of a file handle; Windows also offers window handles and many other kinds of handles. Having said that:

A "memory handle" (that is similar to a pointer to a struct) is a concept from the land of 16-bit Windows programming, where there was no memory manager in the CPU and all memory management had to be done in software. Essentially, a "handle" was sort of a pointer, but the OS would be free to move around the memory that the handle referred to. You can t do that with a regular pointer, but the handle had functions that would get and release the actual memory address.

With the introduction of Win32, where the CPU had a hardware memory manager, the concept of the memory handle became obsolete. Other types of handles such as file handles and window handles still exist in Win32, but are not pointers to structs.

In the old days of MacOS programming, back before OSX, a handle was a pointer to a pointer. That allowed the OS to move things around without invalidating the user s pointers. There were rules on when we could assume the pointed-to object wouldn t move, which I don t remember.

The term handle is used to mean any technique that lets you access to another object. A handle can be a pointer, a reference, a pointer to a pointer, etc.. But sure its related to classes, objects etc. So handle need not always be a pointer to structure.

-AD.

The term "handle" didn t orignate on Windows, though it became widespread among Windows programmers.

In the C standard library (stdio.h), file handles are pointers to a data structure used by the C library.

Pure Unix programming uses file descriptors, which are indexes into a kernel data structure, but pointers have been used as handles in Unix for over 30 years.

"Handle" is a logical term, not a physical one. It s meant as a proxy to a physical object to code that has more intimate knowledge of the object. A pointer to a struct is one such proxy, but there are many other possibilites.

I m probably older than most of the respondents, having earned a living coding in C on both the early (late 80s) Macintosh and both 16 and 32-bit Windows. In those ancient times (when an IBM mainframe might have only 256k of memory) a handle was always a pointer (or table offset) to a memory pointer.

As a previous respondent mentioned, that allowed tables of pointers to memory blocks to be managed by the OS without invalidating the "handles" used by the programmer. Unfortunately, I do not remember how we guaranteed that an allocated block would not be moved while we using the handle.

No, it is not particularly common amongst Windows programmers to refer to pointers as handles, but doing so isn t WRONG either. The term "handle" is usually used to describe something you use to access something through, and in that sense are all pointers handles (but not all handles are pointers). Win32 s handles are AFAIK usually not pointers, but instead indices to internal OS tables - but this might change in future versions of Windows.

A handle is a generic term for a reference (not specifically a C++ reference) to an object.

A pointer is a subset of handle, since it points to objects.

A foreign key in a database is also a handle, since it points to records in other tables; and it is not a pointer.

In the Windows API environment, they used the abstract term handle so they could use an integer into a table, a pointer, or other methods, without interfering with the client; IOW, defining an abstract interface.

In summary, a handle can be something other than a pointer, such as an integer index or an object containing more details about the object (such as a smart pointer).

Windows defines handles for many things. They re not necessarily pointers at all -- some are, but others are things like offsets into particular tables. A few are intentionally obfuscated. There are handles for everything from windows to device contexts to bitmaps, and so on.

In any case, a handle is normally intended as an opaque data type -- i.e. you re not supposed to know anything about its value, only a set of predefined operations that can use it to accomplish various tasks. I believe C++/CLI also has a pointer-like object that s called a handle. I believe it s supposed to be closer to an opaque data type though -- if memory serves, you re not allowed to do any pointer arithmetic on them.

Handles are generally pointers that you don t directly need to dereference. Rather you pass them to API calls which operate on the underlying structs.

Historically on Windows, handles were not pointers. You would lock the handle to get a pointer before using it, and unlock it when you were done (and the pointer would become invalid). In the days before paged memory, old-school Windows did it s own memory management by swapping out resources only referenced by handles and swap them back in when they got locked. In practice, this made memory management a nightmare, but allowed Windows to simulate virtual memory on systems without hardware support for it.

A pointer is definitely different than a handle. A pointer is an address of something unspecified in memory. A pointer to a structure can be called a "handle" (usually by using typedef ).

A handle is a concept used in writing the windows operating system. A pointer is a part of the C language.

Actually a pointer is a variable which contains the address of another variable,but a handle is a pointer to a pointer i.e a pointer which contains the address of another pointer FOR EX:

int x=10;

int *a=&x;// this is a simple pointer

int *b=a;// this is a handle

A handle is a number, the pointer is not a handle

// storage
char data[0xFFFF] = {0} ;

// pointer aka "iterator"
char * storage_pointer = & data[42];

// handle
size_t storage_handle = 42 ;

The key difference or if you prefer to call it the "advantage" of handles is one can try to deduce if the handle is valid or if you prefer the term, "dangling".

I do use handles whenever feasible. Here is a good article on advantages and implementation practices.