Timeline for "observer pointer" meant to stay updated when the pointed object is moved in memory
Current License: CC BY-SA 4.0
24 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 2, 2021 at 18:51 | vote | accept | Barnack | ||
| Apr 2, 2021 at 18:49 | comment | added | Loki Astari | @Barnack G. Sliepen has a good recommendation. | |
| Apr 2, 2021 at 18:48 | comment | added | Barnack | @MartinYork makes sense, thanks! How would you go on naming what in the example is the "Identified" class? Handled sounds a bit off... | |
| Apr 2, 2021 at 18:44 | comment | added | Loki Astari | @Barnack: It's simply the name of the concept you were missing "Handle". They don't need to be in tables (that is just a common implementation) (or even pointers). It's good to use the common name (pattern) to describe what you are trying to achieve. This is a common concept that is used by a lot of OS's to handle resource management. So if you use "Handle_ptr" rather than "self_updating_ptr" everybody that understands the concept of patterns will automatically have an idea of what you are building. | |
| Apr 2, 2021 at 16:36 | comment | added | Barnack | @MartinYork isn't that basically what I've done except mine aren't in a table? Actually sounds really close to G.Sliepen's answer | |
| Apr 2, 2021 at 16:12 | comment | added | Loki Astari | Have you heard of the concept of a "Handle". Basically a pointer to a pointer. User holds the handle that points at a pointer in a table. When an object is moved the table pointer is updated with the new location. The user does not need to know as their pointer simply points to the location of the pointer. | |
| Apr 2, 2021 at 6:00 | history | tweeted | twitter.com/StackCodeReview/status/1377863382360023044 | ||
| Apr 2, 2021 at 2:25 | history | became hot network question | |||
| Apr 1, 2021 at 20:55 | comment | added | ALX23z |
yeah, something like that. I originally thought about coupling the shared_ptr with variables but how you described is more or less the same - only that you suggest that an external class manages the instances update which is probably better.
|
|
| Apr 1, 2021 at 20:25 | answer | added | G. Sliepen | timeline score: 4 | |
| Apr 1, 2021 at 20:09 | history | edited | Barnack | CC BY-SA 4.0 |
Precisation about intended usage
|
| Apr 1, 2021 at 19:59 | comment | added | Barnack | @ALX23z that's actually an alternative I didn't even think about... You mean a large vector for all the instances to be iterated, and a smaller one with dynamically allocated copies for the objects I need to reference from outside, defining a moment in which i update the copies with changes done in the vector, right? | |
| Apr 1, 2021 at 19:55 | comment | added | ALX23z |
@Barnack Correct me if I am wrong, but you don't actually want to keep track of all the objects but only several of them, right? I'd rather use some other methods to keep track of a few objects you need. Say, keep a copy in a separate shared_ptr and update it each time the tracked object is modified.
|
|
| Apr 1, 2021 at 19:47 | comment | added | Barnack | @ALX23z shared_ptr implies that objects won't be necessarily stored sequentially. This thing only observes, the ownership is left outside. I got it, it's not thread safe; and it's not meant nor designed to be, it doesn't want to replace shared_ptr. There won't be concurrent accesses to identifiers. | |
| Apr 1, 2021 at 19:33 | comment | added | ALX23z |
@Barnack I don't understand how your solution is helpful. Here each move of the object requires RAM access to fix the pointer address of identifier. How is that much better than shared_ptr that is non friendly to cache when the object is accessed?
|
|
| Apr 1, 2021 at 19:26 | comment | added | ALX23z | @Barnack I posted a review. This code is very non thread-safe and it is impossible fix it without causing major performance issues. I cannot recommend to use a smart pointer tracker that is not thread-safe. | |
| Apr 1, 2021 at 19:20 | answer | added | ALX23z | timeline score: 3 | |
| Apr 1, 2021 at 19:06 | comment | added | Barnack | @ALX23z say you iterate and re-partition a vector's content thousands of times, and just a dozen times you need to access an element through some externally stored pointer to it. Do you really want to make the thousand iterations go find each object somewhere in the heap just for the sake of the dozen times you need to access an element from outside an iteration? | |
| Apr 1, 2021 at 19:00 | comment | added | Barnack | @ALX23z the functionality shared_ptr cannot provide is sequential storage for multiple objects and having those objects moved around. The whole point here is letting you store objects in some sequential storage like a vector or a deque, freely use algorithms that move things in memory, keeping the external identifiers always valid pointing at the same object. Sequential storage's advantage is cache friendliness, which sometimes one isn't willing to leave out. | |
| Apr 1, 2021 at 18:58 | comment | added | ALX23z |
@Barnack what's the purpose? Isn't easier and safer to simply store the object on the heap as a shared_ptr? What functionality does it add that shared_ptr cannot provide? I mean, beyond being extremely non thread-safe.
|
|
| Apr 1, 2021 at 18:49 | history | edited | Barnack | CC BY-SA 4.0 |
Completed example with support class TmpA and includes
|
| Apr 1, 2021 at 18:37 | comment | added | Barnack | @G.Sliepen for my understanding it has nothing to do with weak_ptr. Weak_ptr doesn't follow the object when it's moved in memory, which is the only thing my code is meant to do. Objects here aren't stored dynamically, they're stored however the user decides to store them. No need to store them in shared pointers. They can be stored sequentially in a vector for instance. | |
| Apr 1, 2021 at 18:31 | comment | added | Barnack | Yay time to check if I just wasted 6 hours of my life... | |
| Apr 1, 2021 at 18:19 | history | asked | Barnack | CC BY-SA 4.0 |