What Is a Handle in C++

pointer vs handles in C (are the terms used to convey separate things?)

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.

What is a handle in C++?

A handle can be anything from an integer index to a pointer to a resource in kernel space. The idea is that they provide an abstraction of a resource, so you don't need to know much about the resource itself to use it.

For instance, the HWND in the Win32 API is a handle for a Window. By itself it's useless: you can't glean any information from it. But pass it to the right API functions, and you can perform a wealth of different tricks with it. Internally you can think of the HWND as just an index into the GUI's table of windows (which may not necessarily be how it's implemented, but it makes the magic make sense).

EDIT: Not 100% certain what specifically you were asking in your question. This is mainly talking about pure C/C++.

HANDLE keyword in C

There is no data type HANDLE declared in standard C. I can't say for sure but most likely this HANDLE is one of the standard Windows Data Types. It would have been introduced by:

#include <windows.h>

A HANDLE is an opaque type used to represent a Win32 object, for example a file, a mutex, an event etc.

What exactly is handle?

A handle is an indirect way to reference an object owned by the OS or a library. When the operating system or a library owns an object but wants to let a client refer to it, it can provide a reference to that object called a handle.

Handles can be implemented in different ways. Typically they are not references in the C++ or C# sense. Often they are pointers cast to some opaque type, or they might be (or contain) an index into a table of objects that are owned by the operating system or library.

For example, in Windows, if you create a window, the OS creates an object that represents the window, but it doesn't return a pointer to that object. Instead, it returns a window handle, which provides an extra layer of indirection. When you pass the window handle back in another OS call, the OS knows which window object to use based on the handle. This prevents your code from directly accessing the window object.

The extra layer of indirection allows the OS or library to do things like move objects around, reference count the objects, and generally control what happens to the object. Like the PIMPL idiom, the implementation may change completely while still preserving the original API and thus not forcing clients to recompile. It's especially useful if you're trying to offer a non-object-oriented API for clients written in procedural languages like C.

What is a Windows Handle?

It's an abstract reference value to a resource, often memory or an open file, or a pipe.

Properly, in Windows, (and generally in computing) a handle is an abstraction which hides a real memory address from the API user, allowing the system to reorganize physical memory transparently to the program. Resolving a handle into a pointer locks the memory, and releasing the handle invalidates the pointer. In this case think of it as an index into a table of pointers... you use the index for the system API calls, and the system can change the pointer in the table at will.

Alternatively a real pointer may be given as the handle when the API writer intends that the user of the API be insulated from the specifics of what the address returned points to; in this case it must be considered that what the handle points to may change at any time (from API version to version or even from call to call of the API that returns the handle) - the handle should therefore be treated as simply an opaque value meaningful only to the API.

I should add that in any modern operating system, even the so-called "real pointers" are still opaque handles into the virtual memory space of the process, which enables the O/S to manage and rearrange memory without invalidating the pointers within the process.

What is the difference between: Handle, Pointer and Reference

A handle is usually an opaque reference to an object. The type of the handle is unrelated to the element referenced. Consider for example a file descriptor returned by open() system call. The type is int but it represents an entry in the open files table. The actual data stored in the table is unrelated to the int that was returned by open() freeing the implementation from having to maintain compatibility (i.e. the actual table can be refactored transparently without affecting user code. Handles can only be used by functions in the same library interface, that can remap the handle back to the actual object.

A pointer is the combination of an address in memory and the type of the object that resides in that memory location. The value is the address, the type of the pointer tells the compiler what operations can be performed through that pointer, how to interpret the memory location. Pointers are transparent in that the object referenced has a concrete type that is present from the pointer. Note that in some cases a pointer can serve as a handle (a void* is fully opaque, a pointer to an empty interface is just as opaque).

References are aliases to an object. That is why you cannot have a reference to a reference: you can have multiple aliases for an object, but you cannot have an alias of an alias. As with pointers references are typed. In some circumstances, references can be implemented by the compiler as pointers that are automatically dereferenced on use, in some other cases the compiler can have references that have no actual storage. The important part is that they are aliases to an object, they must be initialized with an object and cannot be reseated to refer to a different object after they are initialized. Once they are initialized, all uses of the reference are uses of the real object.

What is the difference between a Pointer and a Handle

Sorry, no C# example, but:

Pointer is a memory address, which in this case points to where the object is stored in memory. This is a low level concept that C++ inherited from C.

Regarding the handle:

The term handle is used to mean any technique that lets you get to another object — a generalized pseudo-pointer. The term is (intentionally) ambiguous and vague.

One more important term that is closely related is an object reference, which is an "alias" for the object.

You may get a rather clear and concise answers on this page

FILE vs HANDLE - what is the difference between these two things

FILE is a type of the standard C library, used exclusively for file handling with the stdio.h functions. It cannot be used for anything else. The C standard lib has the advantage of being portable.

HANDLE is a similar but wider concept used by the Windows API, used for everything where they want an abstraction layer on top of raw pointers. It is used for files, ports, threads, mutex, events, pipes and so on. Generally: any Windows resource that you can WaitForSingleObject on - the WaitFor... functions being Window's way of letting a thread effectively sleep without using up CPU resources. See What is a Windows Handle?. It only works for Windows API specific-functions like CreateFile.

Both of these are "opaque types" that the application programmer doesn't know or care about how they are implemented internally.

In practice, the standard C library port for Windows is just an abstraction layer on top of the Windows API. So FILE* fp = fopen("", "w"); will very likely boil down to a CreateFile call internally. So for all we know, FILE could contain a HANDLE internally.

The right type for handles in C interfaces

If you look at how Microsoft defines it's winapi handles (winnt.h) it actually looks like this:

struct HWND__ { int unused; }; typedef struct HWND__ *HWND

in fact they have a macro for this:

#define DECLARE_HANDLE(name) struct name##__{int unused;}; typedef struct name##__ *name

so.. this seems to be a common practice to do so.
Unfortunately I can't make another suggestion except this one, which you already
mentioned, but I hope it helps you anyway.

---

Related Topics