3 ms·

> The natural thing for a context type is something that can be used to directly refer to any object. In today's common architectures this is a pointer. Context

> The natural thing for a context type is something that can be used to directly refer to any object. In today's common architectures this is a pointer. Context APIs that don't support "intptr" or something like it are broken. I want to note the huge disadvantage of using pointers, which is that they aren't mathematical identities, but physical identities. It's place vs value. If you use pointers you are absolutely required to have stable addresses, which means you cannot treat data as what it is: information - and you cannot copy it, move it, duplicate and modify it and such. Because the best handle to it that you have is the memory address where it's supposed to live. You cannot even have parallel arrays (which give modularity) but will end up with god objects amassing unwashed unsorted unrelated incoherent junk data because that's the best to get from an address to actual data. While there are valid uses for pointers (and I don't claim to have any relevant experience with threaded applications), today's popular idea that "something that can be used to refer to any object" is best implemented by a pointer is what really leads to terrible, unmaintainable software.

shawnz 8y ago
Why are stable addresses a problem when you have virtual memory? And even if you didn't, couldn't you just use pointers to pointers?
- jstimpfle 8y ago
  It's an idea I've had for a long time for my applications where (almost) all dynamically are global arrays. 64-bit application have a huge address space and I could simply place each array in a huge subsequence of this address apce. When an array needs to grow I simply mmap() more memory at the end, so I never have to move memory, and all pointers stay valid. I try to avoid pointers to pointers because of the redirection. They are not really solving a problem but only delaying it, at the cost of performance. But first and foremost the biggest problem with pointer is the identity thing. Using a pointer to access various kinds of information either requires that all this information is clumped together (loss of modularity) or at least that we maintain additional lookup structures that bind the disparate information together through indirection (loss of performance, more memory use, more code, and still some loss of modularity).
  - shawnz 8y ago
    > I try to avoid pointers to pointers because of the redirection. They are not really solving a problem but only delaying it, at the cost of performance. Passing an array index and doing an array lookup is also a form of indirection. How is that any different than passing a pointer and doing a pointer dereference? Either way you are not passing the value itself, you are passing a value that represents some kind of memory offset where the real data is stored. It's just that with the array approach, it is a relative offset rather than an absolute one. > Using a pointer to access various kinds of information either requires that all this information is clumped together (loss of modularity) Why does putting all the information together imply a loss of modularity? You could have structs inside structs, defined in separate files, and there would still be no need to dereference twice. Their values will just be stored as part of the enclosing struct's values automatically. You could even reference the specific sub-structs with pointers if you want to keep your modules unaware of the enclosing struct type. Example: https://onlinegdb.com/BJLxqWhuV https://onlinegdb.com/BJLxqWhuV
    - jstimpfle 8y ago
      Just plain global arrays are technically an indirection, but I suppose the performance impact is hard to measure in practice. You have a small number of global pointers (most project will have < 100) that can be expected to be in the L1 cache. The compiler can easily optimize the code by not loading the value of the pointer on each access to an element of the array. Pointers to pointers are one level more of indirection, both the properties I just described are probably not achievable in practice. > Why does putting all the information together imply a loss of modularity? You could have structs inside structs, defined in separate files, Because there is a place that must know them all, bind them all together. And all the client code that wants to use any of the things in there now depends on EACH of them (for a liberal but very real definition of "depends").
      - shawnz 8y ago
        Unless the objects you're working with happen to be contiguously arranged in the arrays then it might be 100 cache lines for those 100 pointers. That's another reason why the "all the data together" approach would probably win performance wise - you'd get 100 whole objects for those 100 cache lines > Because there is a place that must know them all, bind them all together. [...] True, that could be a problem in some circumstances which might warrant a map-like structure like you describe. But I don't think it's the most obvious pattern otherwise

shawnz 8y ago

Why are stable addresses a problem when you have virtual memory? And even if you didn't, couldn't you just use pointers to pointers?

jstimpfle 8y ago
It's an idea I've had for a long time for my applications where (almost) all dynamically are global arrays. 64-bit application have a huge address space and I could simply place each array in a huge subsequence of this address apce. When an array needs to grow I simply mmap() more memory at the end, so I never have to move memory, and all pointers stay valid. I try to avoid pointers to pointers because of the redirection. They are not really solving a problem but only delaying it, at the cost of performance. But first and foremost the biggest problem with pointer is the identity thing. Using a pointer to access various kinds of information either requires that all this information is clumped together (loss of modularity) or at least that we maintain additional lookup structures that bind the disparate information together through indirection (loss of performance, more memory use, more code, and still some loss of modularity).
- shawnz 8y ago
  > I try to avoid pointers to pointers because of the redirection. They are not really solving a problem but only delaying it, at the cost of performance. Passing an array index and doing an array lookup is also a form of indirection. How is that any different than passing a pointer and doing a pointer dereference? Either way you are not passing the value itself, you are passing a value that represents some kind of memory offset where the real data is stored. It's just that with the array approach, it is a relative offset rather than an absolute one. > Using a pointer to access various kinds of information either requires that all this information is clumped together (loss of modularity) Why does putting all the information together imply a loss of modularity? You could have structs inside structs, defined in separate files, and there would still be no need to dereference twice. Their values will just be stored as part of the enclosing struct's values automatically. You could even reference the specific sub-structs with pointers if you want to keep your modules unaware of the enclosing struct type. Example: https://onlinegdb.com/BJLxqWhuV https://onlinegdb.com/BJLxqWhuV
  - jstimpfle 8y ago
    Just plain global arrays are technically an indirection, but I suppose the performance impact is hard to measure in practice. You have a small number of global pointers (most project will have < 100) that can be expected to be in the L1 cache. The compiler can easily optimize the code by not loading the value of the pointer on each access to an element of the array. Pointers to pointers are one level more of indirection, both the properties I just described are probably not achievable in practice. > Why does putting all the information together imply a loss of modularity? You could have structs inside structs, defined in separate files, Because there is a place that must know them all, bind them all together. And all the client code that wants to use any of the things in there now depends on EACH of them (for a liberal but very real definition of "depends").
    - shawnz 8y ago
      Unless the objects you're working with happen to be contiguously arranged in the arrays then it might be 100 cache lines for those 100 pointers. That's another reason why the "all the data together" approach would probably win performance wise - you'd get 100 whole objects for those 100 cache lines > Because there is a place that must know them all, bind them all together. [...] True, that could be a problem in some circumstances which might warrant a map-like structure like you describe. But I don't think it's the most obvious pattern otherwise