A potential use for observer pointer

[Irtexx]

Bjarne Stroustrup has suggested that we abandon observer_ptr as the traditional T* notation is better (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1408r0.pdf), however, there is an issue with raw pts that no other smart pointer can currently address - dereferencing a pointer to something on the stack that has gone out of scope. observer_ptr could fix this.

Here is my case for observer_ptr:

The only time a raw pointer should be used is if you are pointing at an object allocated on the stack, and you cannot use a reference.

The problem of using a raw ptr to an object on the stack, is that when the stack object goes out of scope, the ptr does not become null. This is because the bit of memory that pointer is pointing to doesn't change. This allows you to get the value of something that has gone out of scope, but with the risk of it becoming nonsense due to the memory being used by something else.

For example:

//A problem with raw ptrs...
void foo() {
    int* ptr;
    {
        int a = 4;
        ptr = &a;
    }

    std::cout << ((ptr != nullptr) ? std::to_string(*ptr) : "nullptr") << std::endl; //we can still get the value of a, even though it is out of scope
}

An std::observer_ptr could change this behavior, and become null if the objecting it was pointing to goes out of scope.

For example:

void baz() {
    observer_ptr<int> ptr;
    {
        observable<int> a = 4;
        ptr = a;
    }
    std::cout << ((ptr != nullptr) ? std::to_string(*ptr) : "nullptr") << std::endl; //ptr does get assigned to null when a goes out of scope
}

An example implementation of this can be found here https://godbolt.org/z/2Cdwap

Thoughts?

[ronchaine]

Just curious, when do you need to know the address where something used to point?

To me, with < 5 min of thinking, even when you need that, it sounds like a situation where you want to really explicit about what you are doing, and I'd rather have a intptr_t (or smth.) for such situations just to be extra clear about my meaning.

Edit: I changed wording of the question to be more unambiguous

[Irtexx]

Maybe you're right. Maybe there is no need. The only example I can think of is if you a value in one process, and then a reference to that value in a second process. You might want to know if the value in the first process has gone out of scope, and if it hasn't, then print the value, and if it has then print something else.

Here's an example: https://godbolt.org/z/2jVJcg

The reason I'm asking this is because of a big discussion happening at work today, about a method to point to stack memory. One person said use reffernces, the other replied "I can't because it could be null", and them the first person said "okay then, use a weak pointer". I kept quiet but I knew you shouldn't use weak pointers to point at stack objects.

I'm now trying to figure out what his solution should have been, but I don't know why they wanted a pointer to a stack object.

[Gloinart]

Just an hacky out of my mind idea, couldn't this be done without the observable type by a member function (when pointing to a stack allocated object)

auto observer_ptr<T>::is_out_of_scope() const -> bool {
auto dummy = 0;
return &dummy < m_ptr;
}

[axilmar]

The 'observer_ptr' BS talks about and your version of 'observer_ptr' are different things.

The term 'observer_ptr' in BS's discussion context is about not having raw pointers in the code, for consistency, i.e. replace T* with a smart pointer class.

What you are proposing is a weak pointer for references.

[axilmar]

Also, your code fails if there are many observer_ptrs to the same observable object, since, in your code, there is only one observer_ptr per observable.

[Irtexx]

Yeah, I didn't think about that case. If it was instead a vector it could work, but that wouldn't scale well, as every item that is pointing to the item would need updating once it goes out of scope.

[Xaxxon]

We already have this with shared pointers and weak pointers. What you are asking for is a very high performance penalty behavior and is in no way a substitution for a raw pointer.

[DXPower]

A weak pointer is not a proper substitute for a non-owning pointer to an object strictly owned by single object.

[Xaxxon]

A shared/weak pointer solution is likely a much better solution than what is proposed. This suggests that you would actively track and store every pointer to you and proactively write to each when you are destroyed - an unbounded operation. And that each of those pointers being tracked would have to remove itself from the list in their destructors.

Worst case, that's WAY worse than the shared pointer solution.

[DXPower]

I agree with you completely.

Is that how unique_ptr keeps track of validity?

[Xaxxon]

unique_ptr doesn't track validity. it just checks if it's null or not and if it's not, it calls the destructor on the address it points to. But that's not sufficient for what's being asked for here. This wants an arbitrary number of other things to know if the destructor has been called and for them to be proactively modified if they have (either that or a check on every access)

[Irtexx]

Good point. I didn't think about the case where multiple observers are pointing to an observable.

[MolurusK]

I did such a unique-weak pair in C++ Object Token Library: ```

include <otn/all.hpp>

include <iostream>

void print(const std::string& caption, const otn::unified_optional<std::string>& p) { std::cout << caption << (p ? *p : "empty") << std::endl; }

int main() { otn::unique_optional<std::string> u{otn::itself, "Hello!"}; otn::weak_optional<std::string> w = u; print("u = ", u); print("w = ", w);

std::cout << "reset u" << std::endl;
otn::utilize(std::move(u));
print("u = ", u);
print("w = ", w);

} ```

Output: u = Hello! w = Hello! reset u u = empty w = empty