reference to *this in initialization list?

having some access violations and i'm guessing it has something to do with aforementioned.

is something like this unsafe:

Code:

---

object():
    memberThatReferencesThis(*this)
{
}

---

It doesn't seem like a particularly good idea to have a reference in an object that refers to the object itself - I don't really see any purpose in that.

--
Mats

It should be safe.

Quote:

---

It doesn't seem like a particularly good idea to have a reference in an object that refers to the object itself - I don't really see any purpose in that.

---

A member might need to know about the owner class, so it can call it back. I assume that's a constructor call, not an initialization of the reference of the same type.

there's an excellent purpose, however there may be a better way of doing it.

i have a container class (tasklist) for functors (task). they have a method called exec where it iterates over a vector<task*>tasks. i require every task to have a tasklist owner that deletes it when the tasklist destructor. in an unrealted note, task has a vector called "remove from" that it iterates over in it's destructor to remove pointers to itself so that the tasklists always have valid pointers in their vector<task*>tasks.

where this problem surfaces is that each tasklist has a member task 'run' in it that calls exec for that tasklist. run is owned by this.

and actually, at the time of my post, i was using borland's DynamicArray class. switching to std::vector fixed the problem. (or at least covered it up for the time being, but i suspect things are ok now)

hooray stl.

Quote:

---

Originally Posted by anon

It should be safe.



A member might need to know about the owner class, so it can call it back. I assume that's a constructor call, not an initialization of the reference of the same type.

---

thanks; and yes, you have surmised correctly.

What might not be safe is to assume is that the object that the reference refers to is fully constructed at that point. So you can initialize the reference safely, but I don't think you should use it to call back the parent in the constructor.

i put toDestroy ahead of run in the initialization list :)

Quote:

---

Originally Posted by m37h0d

having some access violations and i'm guessing it has something to do with aforementioned.

is something like this unsafe:

Code:

---

object():
    memberThatReferencesThis(*this)
{
}

---

---

It's safe so long as the constructor for the member doesn't attempt to access the reference. But the compiler warnings are annoying, so what I've done in the past is have the memberThatReferencesThis hold it as a pointer instead of a reference, and do something like this:

Code:

---

object()
{
    memberThatReferencesThis.setContainer(this);
}

---

This method avoids the warning as well as the lingering doubts that you are doing something undefined.

What about the boost::enable_from_this template?
I remember reading about it in my Boost book, but I've never used it. Sounds like it might be useful in this situation though.

Quote:

---

Originally Posted by anon

A member might need to know about the owner class, so it can call it back. I assume that's a constructor call, not an initialization of the reference of the same type.

---

When I've done this, it's to implement multiple interfaces on an underlying object. Each interface proxies to the object through the "this" pointer which was set up during construction of the object.

In C++ you could theoretically achieve the same thing through multiple inheritance, but that introduces other issues.

It comes up a lot in COM programming.

brewbuck - it seems happy enough when i declare the vectors first in the initialization list. so i guess it's one of those 'it works but carries caveats' kinda things.

i was doing it with pointers before, just the way you said, without issue. but i've been using references everywhere else where the location binding is mandatory, as it is here, so i want to keep things as syntactically consistent as possible for my own sanity.

blah toDestroy needs to be a shared_ptr to support proper copy semantics i think...

do i need to do anything besides stick boost in my include path to start using it? i don't think this is one of the libraries it said had to be built...

The Smart Ptr library is all templates, so no need to build anything beforehand.

ok. this is my first stab at using boost - any must reads (besides "TFM") or other pointers before i go at it?

Quote:

---

Originally Posted by m37h0d

ok. this is my first stab at using boost - any must reads (besides "TFM") or other pointers before i go at it?

---

I've never needed anything but the doc web pages. Before using boost you probably want to consider whether you want to create a dependency on an external library. As cpjust said, a lot (the majority?) of Boost's functionality is contained in header files, but there are a few things, like the regex library, which need to be compiled.

Boost is very portable, but it's something to consider before using it.

(Some detective might dig up a comment I made recently about feeling good about using Boost in any given project -- I was referring to the functionality you get from headers only)

yeah, i still want to use it for other reasons, but i've decided that this 'owner' pattern is just evil and lazy. i'll just keep track of them another way.