1

I have read this article and I encountered the following

A resource handle can be an opaque identifier, in which case it is often an integer number (often an array index in an array or "table" that is used to manage that type of resource), or it can be a pointer that allows access to further information.

So a handle is either an opaque identifier or a pointer that allows access to further information. But from what I understand, these specific pointers are opaque pointers, so what exactly is the difference between these pointers ,which are opaque pointer, and opaque identifiers?

  • A "handle" can be an integer or a pointer, and either be opaque or not (though they usually are opaque, at least to the user). – DevSolar Dec 01 '17 at 22:50
  • And even what is making something "opaque" is somewhat [up to discussion](https://stackoverflow.com/a/3854144/60281)... – DevSolar Dec 01 '17 at 22:52
  • 4
    They are opaque in that you don't really know what they are. They could be integers, they could be pointer, they could be hamsters. You don't know and the implementation can swap out whatever the hell they are on you without you being any wiser. – user4581301 Dec 01 '17 at 22:52
  • 3
    "*So a handle is either an opaque identifier or a pointer that allows access to further information*" - no, it is always opaque, period. It MAY be implemented as an integer, or it MAY be implemented as a pointer. You don't know what it is, nor should you care since you can't do anything direct with it, all you can do is pass it back to an API that knows what to do with it – Remy Lebeau Dec 01 '17 at 23:02
  • @RemyLebeau but still, when they certainly are referring to opaque pointers, they differentiate between opaque identifiers and opaque pointers by mentioning them as two different things... But then what is the difference between opaque identifiers and opaque pointers? Aren't opaque identifiers just identifiers of opaque data types? –  Dec 01 '17 at 23:09
  • If so, and opaque data types could be an opaque pointer, is there any difference? –  Dec 01 '17 at 23:10
  • To you they are just bytes. Don't over-explain this stuff. –  Dec 01 '17 at 23:20
  • 1
    It is opaque in the sense that you never actually care what the type looks like. There will always be a function that creates the handle, it usually has a dunno* argument or dunno return value. And a function that destroys it, it has a dunno argument. And several functions that execute operations, they have a dunno argument. Usually declared as void*, sometimes int or long, sometimes it is even a struct to make it typesafe if the api has different handle types. – Hans Passant Dec 01 '17 at 23:32
  • 2
    @step: "*they differentiate between opaque identifiers and opaque pointers by mentioning them as two different things*" One is a pointer; the other is not. That's the difference. Just as there's a difference between a `void*` and an `uintptr_t`. – Nicol Bolas Dec 01 '17 at 23:39
  • The kicker is don't make any decisions based on anything you can infer from the opaque identifier. Don't make any educated guesses. Even if they are true today, one upgrade, patch, or seemingly inconsequential change could make you wrong. Relying on a `HANDLE` to be anything but a`HANDLE` will result in brittle code. – user4581301 Dec 01 '17 at 23:45

5 Answers5

3

One of the literal meanings of "opaque" is "not transparent".

In computer science, an opaque identifier or a handle is one that doesn't expose its inner details. This means we can only access information from it by using some defined interface, and can't otherwise access information about its value (if any) or internal structure.

As an example, a FILE in the C standard library (and available in C++ through <cstdio>) is an opaque type. We don't know if it is a data structure, an integer, or anything else. All we know is that a set of functions, like fopen() return a pointer to one (i.e. a FILE *) and other functions (fclose(), fprintf(), ....) accept a FILE * as an argument. If we have a FILE *, we can't reliably do anything with it (e.g. actually write to a file) unless we use those functions.

The advantage of that is it allows different implementations to use different ways of representing a file. As long as our code uses the supplied functions, we don't have to worry about the internal workings of a FILE, or of I/O functions. Compiler vendors (or implementers of the standard library) worry about getting the internal details right. We simply use the opaque type FILE, and pointers to it, and stick to using standard functions, and our code works with all implementations (compilers, standard library versions, host systems)

An opaque identifier can be of any type. It can be an integer, a pointer, even a pointer to a pointer, or a data structure. Integers and pointers are common choices, but not the only ones. The key is only using a defined set of operations (i.e. a specific interface) to interact with those identifiers, without getting our hands dirty by playing with internal details.

Peter
  • 35,646
  • 4
  • 32
  • 74
1

A handle is said to be "opaque" when client code doesn't know how to see what it references. It's simply some identifier that can be used to identify something. Often it will be a pointer to an incomplete type that's only defined within a library and who's definition isn't visible to client code. Or it could just be an integer that references some element in some data structure. The important thing is that the client doesn't know or care what the handle is. The client only cares that it uniquely identifies some resource.

Consider the following interface:

widget_handle create_widget();
void do_a_thing(widget_handle);
void destroy_widget(widget_handle);

Here, it doesn't actually matter to the calling code what a widget_handle is, how the library actually stores widgets, or how the library actually uses a widget_handle to find a particular widget. It could be a pointer to a widget, or it could be an index into some global array of widgets. The caller doesn't care. All that matters is that it somehow identifies a widget.

Miles Budnek
  • 28,216
  • 2
  • 35
  • 52
0

One possible difference is that an integer handle can have "special" values, while pointer handle cannot.

For example, the file descriptors 0,1,2 are stdin, stdout, stderr. This would be harder to pull off if you have a pointer for a handle.

  • Well almost all pointer based systems have a special value for "NULL". But to get more general ones, one just declares a global object and uses its address for the special pointer value. Re: stdin etc. std::cin exists... – Zalman Stern Dec 01 '17 at 23:34
  • @ZalmanStern Very true. However, with integer descriptors you don't need global variables. –  Dec 01 '17 at 23:36
0

You really you shouldn't care. They could be everything.

Suppose you buy a ticket from person A for an event. You must give this ticket to person B to access the event.

The nature of the ticket is irrelevant to you, it could be:

  • a paper ticket,
  • an alphanumerical code,
  • a barcode,
  • a QR-Code,
  • a photo,
  • a badge,
  • whatever.

You don't care. Only A and B use the ticket for its nature, you are just carrying it around. Only B knows how to verify the validity and only A know how to issue a correct ticket.

An opaque pointer could be a memory location directly, while an integer could be an offset of a base memory address in a table but how is that relevant to you, client of the opaque handle?

Jack
  • 131,802
  • 30
  • 241
  • 343
0

In classic Mac OS memory management, handles were doubly indirected pointers. The handle pointed to a "master pointer" which was the address of the actual data. This allowed moving the actual storage of the object in memory. When a block was moved, its master pointer would be updated by the memory manager.

In order to use the data the handle ultimately referenced, the handle had to be locked, which would prevent it being moved. (There was little concurrency in the system so unless one was calling the operating system or libraries which might, one could also rely on memory not getting moved. Doing so was somewhat perilous however as code often evolved to call something that could move memory inside a place where that was not expected.)

In this design, the handle is a pointer but it is not an opaque type. A generic handle is a void ** in C, but often one had a typed handle. If you look here you'll find lots of handle types that are more concrete. E.g. StringHandle.

Zalman Stern
  • 3,161
  • 12
  • 18