3 ms·

As I see it, this just isn't true. I think you're going to have to elaborate on this with an actual concrete example (i.e. code) if you'd like to make a convinc

As I see it, this just isn't true. I think you're going to have to elaborate on this with an actual concrete example (i.e. code) if you'd like to make a convincing argument.

stephc_int13 6y ago
You'll have to wait until I publish my article on this subject if you want to see some code. But can you agree that a pointer does not give you anything else than a direct reference to a memory area? Because of the indirection, a handle can do much more, depending on the implementation.
- dataflow 6y ago
  > But can you agree that a pointer does not give you anything else than a direct reference to a memory area? Depends what you mean. Not if I take it literally, given you can generally shove a few extra bits into pointers. But in a sense it's approximately true. > Because of the indirection, a handle can do much more, depending on the implementation. Not unless you're playing semantics with what "handle" means. I'm going on the assumption that we can assume it's an opaque reference of equal size as a pointer to data that is or will be in the machine's user-mode memory. If that's not what you mean, then this is a seriously pointless argument, given you can obviously define "handles" to anything (even data on another machine) where nobody in their right mind would be arguing you could just replace it with a pointer... Again, this is why you really need to provide examples to make a convincing argument (and you really can't expect people to wait for you to publish an article if you're going to bring it up beforehand). So we don't end up arguing over something that turns out to be pointless.
  - stephc_int13 6y ago
    If you shove a few extra bits into a pointer, then it can't directly be used to dereference something. In practice it would be what I call an immediate handle (a handle that can be resolved to a pointer with a test and simple bitmask) void* ResolveHandle(handle h); this is the basic API, and it will return nullptr if this handle is not allocated or has been freed. Or it will block if this handle is a promise. The handle itself can be an index, but also the hash of a string, the string being a path to a ressource that is not even loaded yet.
    - dataflow 6y ago
      > If you shove a few extra bits into a pointer, then it can't directly be used to dereference something. In practice it would be what I call an immediate handle (a handle that can be resolved to a pointer with a test and simple bitmask) That's just a smart pointer. Unlike a handle, it's anything but opaque. (And in your comment you specifically lumped smart pointers under "pointers" too, so we should be in agreement.) > void* ResolveHandle(handle h); this is the basic API, and it will return nullptr if this handle is not allocated or has been freed. Or it will block if this handle is a promise. Again, there's nothing preventing you from making a smart pointer that does exactly what you're talking about here, which (again) both of us would lump under "pointer". Perhaps worth elaborating on: The concepts of handles and pointers, as I'm talking about them at least, are fairly language-agnostic. What makes a handle a "handle" to me (and I would've thought to you too) isn't the wrapper around it; it's the opaqueness. Not from a mechanical sense (i.e. not the public vs. private or the language syntax, which aren't even relevant in every language) but from an informational sense: whether it can be "dereferenced" without additional information.
  - loup-vaillant 6y ago
    > I'm going on the assumption that we can assume it's an opaque reference of equal size as a pointer to data that is or will be in the machine's user-mode memory. If the handle is an array index or a hash, it can be much smaller than a pointer. 8 bits in extreme cases, often 16 bits (if there's only a few thousands objects of that type), and we almost never ever need more than 32 bits. Such handles can easily have less memory overhead than actual pointers, even after accounting for the redundancies needed for some runtime checks.
deleted 6y ago
[deleted]
xaedes 6y ago
"pointer is not giving you much information about the availability of the data behind it" "elaborate on this with an actual concrete example" The pointer may get invalidated, for example by reallocation of the underlying data structure: #include <iostream> #include <vector> struct ItemPrinter { int* ptr; void print() { std::cout << (*ptr) << std::endl; }; }; int main() { std::vector<int> items{1}; ItemPrinter foo{&(items[0])}; while(items.size()<1000) { foo.print(); items.push_back(2); } } When push_back exceeds the vector capacity, it needs to reallocate and `foo.ptr` gets invalidated. Output when executed via http://cpp.sh/ http://cpp.sh/ 1 0 1 1 35557904 35557904

As I see it, this just isn't true. I think you're going to have to elaborate on this with an actual concrete example (i.e. code) if you'd like to make a convincing argument.

stephc_int13 6y ago

You'll have to wait until I publish my article on this subject if you want to see some code. But can you agree that a pointer does not give you anything else than a direct reference to a memory area? Because of the indirection, a handle can do much more, depending on the implementation.

dataflow 6y ago
> But can you agree that a pointer does not give you anything else than a direct reference to a memory area? Depends what you mean. Not if I take it literally, given you can generally shove a few extra bits into pointers. But in a sense it's approximately true. > Because of the indirection, a handle can do much more, depending on the implementation. Not unless you're playing semantics with what "handle" means. I'm going on the assumption that we can assume it's an opaque reference of equal size as a pointer to data that is or will be in the machine's user-mode memory. If that's not what you mean, then this is a seriously pointless argument, given you can obviously define "handles" to anything (even data on another machine) where nobody in their right mind would be arguing you could just replace it with a pointer... Again, this is why you really need to provide examples to make a convincing argument (and you really can't expect people to wait for you to publish an article if you're going to bring it up beforehand). So we don't end up arguing over something that turns out to be pointless.
- stephc_int13 6y ago
  If you shove a few extra bits into a pointer, then it can't directly be used to dereference something. In practice it would be what I call an immediate handle (a handle that can be resolved to a pointer with a test and simple bitmask) void* ResolveHandle(handle h); this is the basic API, and it will return nullptr if this handle is not allocated or has been freed. Or it will block if this handle is a promise. The handle itself can be an index, but also the hash of a string, the string being a path to a ressource that is not even loaded yet.
  - dataflow 6y ago
    > If you shove a few extra bits into a pointer, then it can't directly be used to dereference something. In practice it would be what I call an immediate handle (a handle that can be resolved to a pointer with a test and simple bitmask) That's just a smart pointer. Unlike a handle, it's anything but opaque. (And in your comment you specifically lumped smart pointers under "pointers" too, so we should be in agreement.) > void* ResolveHandle(handle h); this is the basic API, and it will return nullptr if this handle is not allocated or has been freed. Or it will block if this handle is a promise. Again, there's nothing preventing you from making a smart pointer that does exactly what you're talking about here, which (again) both of us would lump under "pointer". Perhaps worth elaborating on: The concepts of handles and pointers, as I'm talking about them at least, are fairly language-agnostic. What makes a handle a "handle" to me (and I would've thought to you too) isn't the wrapper around it; it's the opaqueness. Not from a mechanical sense (i.e. not the public vs. private or the language syntax, which aren't even relevant in every language) but from an informational sense: whether it can be "dereferenced" without additional information.
- loup-vaillant 6y ago
  > I'm going on the assumption that we can assume it's an opaque reference of equal size as a pointer to data that is or will be in the machine's user-mode memory. If the handle is an array index or a hash, it can be much smaller than a pointer. 8 bits in extreme cases, often 16 bits (if there's only a few thousands objects of that type), and we almost never ever need more than 32 bits. Such handles can easily have less memory overhead than actual pointers, even after accounting for the redundancies needed for some runtime checks.

deleted 6y ago

[deleted]

xaedes 6y ago

"pointer is not giving you much information about the availability of the data behind it" "elaborate on this with an actual concrete example" The pointer may get invalidated, for example by reallocation of the underlying data structure: #include <iostream> #include <vector> struct ItemPrinter { int* ptr; void print() { std::cout << (*ptr) << std::endl; }; }; int main() { std::vector<int> items{1}; ItemPrinter foo{&(items[0])}; while(items.size()<1000) { foo.print(); items.push_back(2); } } When push_back exceeds the vector capacity, it needs to reallocate and `foo.ptr` gets invalidated. Output when executed via http://cpp.sh/ http://cpp.sh/ 1 0 1 1 35557904 35557904