Is it possible to test if a raw pointer is pointing to a valid object?

[JiiPee]

First the code. The question below it:

------------------------
class Parent
{
public:
void foo2() {}
};

class Child
{
public:
Parent* m_parent{nullptr};
void foo() {
// can the validity of the raw pointer m_parent be checked?
m_parent->foo2();
}
};

void main()
{
Parent* parent = new Parent;
Child child;
child.m_parent = parent;
delete parent;
child.foo(); // any way this call knowing parent is now deleted?

}

------------------

Is there any way to check if a raw pointer is pointing to a valid object?
Because I have situations where I can only store raw pointers.
I know it can be done with shared pointers, but how about raw pointers?
Assuming I cannot change the Parent class in the above example.
Or is there any pattern applied to Child class... again assuming we
cannot change the Parent class at all.

[Paavo Helde]

24.08.2022 20:00 JiiPee kirjutas:
> First the code. The question below it:
>
> ------------------------
> class Parent
> {
> public:
>     void foo2() {}
> };
>
> class Child
> {
> public:
>     Parent* m_parent{nullptr};
>     void foo() {
>         // can the validity of the raw pointer m_parent be checked?
>         m_parent->foo2();
>     }
> };
>
> void main()
> {
>     Parent* parent = new Parent;
>     Child child;
>     child.m_parent = parent;
>     delete parent;
>     child.foo(); // any way this call knowing parent is now deleted?

No, there isn't any way. At best you can check if a pointer points to
memory page which is readable or writable for the process, but that does
not help much.

>
> }
>
> ------------------
>
> Is there any way to check if a raw pointer is pointing to a valid object?
> Because I have situations where I can only store raw pointers.
> I know it can be done with shared pointers, but how about raw pointers?
> Assuming I cannot change the Parent class in the above example.
> Or is there any pattern applied to Child class... again assuming we
> cannot change the Parent class at all.

The tedious way is to not delete parent without informing all the
children that the parent is dead.

A smarter pattern is smart pointers. You do not need to modify Parent
class for using smart pointers on it.

class Child
{
public:
std::weak_ptr<Parent> m_parent;
void foo() {
if (auto parent = m_parent.lock()) {
parent->foo2();
}
}
};



void main()
{
std::shared_ptr parent = std::allocate_shared<Parent>();

Child child;
child.m_parent = parent;

parent = nullptr; // deletes parent
child.foo(); // OK
}

[Paavo Helde]

24.08.2022 20:24 Paavo Helde kirjutas:

>   std::shared_ptr parent = std::allocate_shared<Parent>();

Sorry, this should have been std::make_shared<Parent>();

[JiiPee]

On 24/08/2022 20:24, Paavo Helde wrote:
> The tedious way is to not delete parent without informing all the
> children that the parent is dead.

Yes but then would need to change the Parent. Which I cannot really do.

>
> A smarter pattern is smart pointers. You do not need to modify Parent
> class for using smart pointers on it.

Yes I know this... and this is obviously best way to do it if can.

[JiiPee]

On 24/08/2022 20:29, Stefan Ram wrote:
> You could write management functions that take care
> of the notifications required:

Yes possible, and good if can change parent. But that would need to
change the Parent class which I cannot always do.

[Keith Thompson]

Paavo Helde <ees...@osa.pri.ee> writes:
> 24.08.2022 20:00 JiiPee kirjutas:
>> First the code. The question below it:
>> ------------------------
>> class Parent
>> {
>> public:
>>     void foo2() {}
>> };
>> class Child
>> {
>> public:
>>     Parent* m_parent{nullptr};
>>     void foo() {
>>         // can the validity of the raw pointer m_parent be checked?
>>         m_parent->foo2();
>>     }
>> };
>> void main()
>> {
>>     Parent* parent = new Parent;
>>     Child child;
>>     child.m_parent = parent;
>>     delete parent;
>>     child.foo(); // any way this call knowing parent is now deleted?
>
> No, there isn't any way. At best you can check if a pointer points to
> memory page which is readable or writable for the process, but that
> does not help much.

There's no portable way to do even that.

[...]

> void main()

Of course main returns int, not void. (I know that was in the parent
article.)

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[JiiPee]

On 24/08/2022 20:44, Keith Thompson wrote:
>> void main()
> Of course main returns int, not void. (I know that was in the parent
> article.)

but its shorter to type, hehe

[JiiPee]

actually compiles in visual studio

[Keith Thompson]

Most C++ compilers aren't fully conforming by default. Any conforming
C++ implementation must diagnose `void main()` (and may then either
accept it or reject it).

[Malcolm McLean]

The only way to do it is to overload the new and delete operators to maintain a
table of valid pointers. You can then test the pointers for validity (though note
that memory might be re-used, so you have to have something more sophisticated
than a simple list).
This isn't practical unless you are building a system from the ground up.

[Louis Krupp]

Wild guess: Could you have a class that contains a Parent object and
calls its methods while doing notifications and anything else you need?
If you don't use pointers to the Parent class itself, you might not have
to change it.

Louis

[JiiPee]

On 24/08/2022 22:45, Malcolm McLean wrote:
> The only way to do it is to overload the new and delete operators to maintain a
> table of valid pointers.

Yes, that is a new idea. At least can consider...

[Scott Lurndal]

If every class derives from a common base class, the base class
can contain a magic number that identifies the object as valid.

e.g.

class Object {
static const uint64_t MAGIC_NUMBER = 0x23324abc3242ffaaul;
uint64_t o_magic;

public:
Object(void) : o_magic(MAGIC_NUMBER) {}

bool is_valid(void) const { return o_magic == MAGIC_NUMBER; }
};

class MyObject : Object {
...
};

MyObject *objp = ...;

if (objp->is_valid()) {
this is a valid, initialized object.
}


This approach also allows some degree of introspection if you
add additional member functions to the Object class.

The JAVA object system uses this concept.

[Malcolm McLean]

On some systems, if you delete objp, then call is_valid() on it, you
will get a segmentation fault. The implementation efectively has its
own mechanism for checking for valid objects, and "protects" the
program by shutting it down if an invalid object is accessed.

[Sam]

JiiPee writes:

> Is there any way to check if a raw pointer is pointing to a valid object?

No there isn't. End of story.

[Bonita Montero]

Am 24.08.2022 um 19:00 schrieb JiiPee:

> Is there any way to check if a raw pointer is pointing to a valid object?

What's the practical use of that ?

[Malcolm McLean]

When you don't have good communications between the part of the program
which is deleting an object, and a part which holds a reference to it.
For example we have a plugin architecture. A plugin can't call another plugin's
"update pointers" routine when it deletes a shared object. Fortunately the system
provides an "is_valid" method, so you can guard against objects being deleted
when it's your turn for the processor.

[Vir Campestris]

On 24/08/2022 22:57, Malcolm McLean wrote:
> On some systems, if you delete objp, then call is_valid() on it, you
> will get a segmentation fault. The implementation efectively has its
> own mechanism for checking for valid objects, and "protects" the
> program by shutting it down if an invalid object is accessed.

That's not reliable unless you can guarantee that an area of memory is
never re-used.

You can only make that guarantee if you know you will never run out of
address space.

Remember that this also requires that each object will need to exist in
its own page, so their memory allocations will be padded out to a page
boundary - typically an average of 2k for every single object.

I had this problem when I started my last job, and I re-architected all
the pointers to a particular object to be shared pointers. It was a
PITA, resulted in senior engineers asking who the hell was I (and
luckily getting a calming reply), resulted in a memory leak a bit later
- and made that build the most reliable we'd ever had.

Andy

[Sam]

Malcolm McLean writes:

> On Thursday, 25 August 2022 at 06:39:56 UTC+1, Bonita Montero wrote:
> > Am 24.08.2022 um 19:00 schrieb JiiPee:
> >
> > > Is there any way to check if a raw pointer is pointing to a valid object?
> > What's the practical use of that ?
> >
> When you don't have good communications between the part of the program
> which is deleting an object, and a part which holds a reference to it.

Well, that's the real problem that needs to be solved, and not the one about
determining if a pointer is "valid", in some way, or not.

That's because the latter is unsolvable in C++, so there aren't any other
options.

[JiiPee]

On 25/08/2022 13:37, Malcolm McLean wrote:
> On Thursday, 25 August 2022 at 06:39:56 UTC+1, Bonita Montero wrote:
>> Am 24.08.2022 um 19:00 schrieb JiiPee:
>>
>>> Is there any way to check if a raw pointer is pointing to a valid object?
>> What's the practical use of that ?
>>
> When you don't have good communications between the part of the program
> which is deleting an object, and a part which holds a reference to it.

Yes. When the classes cannot much communicate, and then the other class
deletes that pointer... then my class somehow needs to be sure its still
valid.

I created a button group manager, which stores pointers pointing to
existing buttons. But how can this manager know if the button still
exists... and that was the issue. I was just wondering is its poissible
without changing code around the class.

[Chris M. Thomasson]

Sounds like a need for a proper Lifetime Management protocol...

[Sam]

JiiPee writes:

> On 25/08/2022 13:37, Malcolm McLean wrote:
>> On Thursday, 25 August 2022 at 06:39:56 UTC+1, Bonita Montero wrote:
>>> Am 24.08.2022 um 19:00 schrieb JiiPee:
>>>
>>>> Is there any way to check if a raw pointer is pointing to a valid object?
>>> What's the practical use of that ?
>>>
>> When you don't have good communications between the part of the program
>> which is deleting an object, and a part which holds a reference to it.
>
> Yes. When the classes cannot much communicate, and then the other class
> deletes that pointer... then my class somehow needs to be sure its still
> valid.

If the "other class deletes that pointer", then the other class must
directly, or indirectly, make provisions for that. Nothing in C++ happens
automatically, by magic.

> I created a button group manager, which stores pointers pointing to existing
> buttons. But how can this manager know if the button still exists... and
> that was the issue. I was just wondering is its poissible without changing
> code around the class.

If there's something that called a "button group manager", that's
responsible for managing these "buttons", but this manager isn't the one
that's creating these buttons, then there must be some formal process by
which thus "button group manager" must become aware of these buttons,
somehow. That also doesn't happen automatically, by magic. There must be
some procedure by which these buttons get handed over to this "button group
manager".

Therefore, there must also be a procedure by which this "button group
manager" must be notified that a particular button should no longer be under
its control. So, whatever this process or procedure is, it needs to be used
before deleting this button, so that the "button group manager" does not use
a pointer to a deleted object.

The End.

[Manfred]

On 8/24/2022 8:59 PM, Keith Thompson wrote:
> JiiPee <kerrttuPo...@gmail.com> writes:
>> On 24/08/2022 20:51, JiiPee wrote:
>>> On 24/08/2022 20:44, Keith Thompson wrote:
>>>>> void main()
>>>> Of course main returns int, not void.  (I know that was in the parent
>>>> article.)
>>> but its shorter to type, hehe
>>
>> actually compiles in visual studio
>
> Most C++ compilers aren't fully conforming by default. Any conforming
> C++ implementation must diagnose `void main()` (and may then either
> accept it or reject it).
>

Curiously, the C standard poses no requirements on main() for
freestanding implementations.
Apparently the C++ standard does instead: it says that main() may not be
present in a freestanding implementation, but, as it is written, if it
is present then it must have int return type.

[Paul N]

Can't you make it that only the manager can delete buttons? That way the manager will always know what buttons are there and which are not. It seems a reasonable responsibility for a "manager" to have. Other parts of the program can request the manager to delete a button, but they don't actually do it themselves.

[JiiPee]

On 26/08/2022 15:49, Paul N wrote:
> Can't you make it that only the manager can delete buttons?

Not really, because I cannot really touch much the existing code....
that would require re-testing etc.... so its not so easy.

[Louis Krupp]

Could you create an intermediate subclass of Parent that would add the
required functionality?

A crude outline:

===
class Parent // can't be modified
{
public:
    void foo2() {}
};

class Nanny : public Parent
{
public:
   Nanny(Parent* parentptr, Child* childptr) : Parent(parentptr); //
keep list of children
   ~Nanny(); // notify children of nanny's impending deletion by
calling Child::nanny_byebye
}

class Child
{
public:
    Nanny* m_nanny{nullptr, this}; // add child to list
    void nanny_byebye() {
        m_nanny = nullptr;
    }
    void foo() {
        // check to see if nanny has been deleted
        if (m_nanny) m_nanny->foo2();
    }
};

void main()
{
    Parent* nanny = new Nanny;
    Child child;
    child.m_nanny = nanny;
    delete nanny;
    child.foo(); // Nanny::foo2 won't be called

}
===

Louis

[Lynn McGuire]

On 8/24/2022 12:00 PM, JiiPee wrote:
> First the code. The question below it:
>
> ------------------------
> class Parent
> {
> public:
>     void foo2() {}
> };
>
> class Child
> {
> public:
>     Parent* m_parent{nullptr};
>     void foo() {
>         // can the validity of the raw pointer m_parent be checked?
>         m_parent->foo2();
>     }
> };
>
> void main()
> {
>     Parent* parent = new Parent;
>     Child child;
>     child.m_parent = parent;
>     delete parent;
>     child.foo(); // any way this call knowing parent is now deleted?
>
> }
>
> ------------------
>

> Is there any way to check if a raw pointer is pointing to a valid object?

> Because I have situations where I can only store raw pointers.
> I know it can be done with shared pointers, but how about raw pointers?
> Assuming I cannot change the Parent class in the above example.
> Or is there any pattern applied to Child class... again assuming we
> cannot change the Parent class at all.

Yes. You need to wrap new, realloc, malloc, and free with your own code
and keep track of all your memory allocations.

Lynn