0

say we have:

class A
{
    void Func(std::function<void(void)> handler);
}

class B
{
    A myObj;

    B()
    {
        myObj.Func([this]()
        {
            //whatever
        });
    }
}

That makes myObj (of type A) have a reference to lambda object, lambda object has reference to B object (through captured 'this'), and B object (captured 'this') has reference to myObj (of type A), which means a cyclic dependency has occurred, right?

I know the solution lies in the use of std::weak_ptr somehow, but I am having trouble understanding how to properly use them to solve this case. Could anyone help with a solution for this example?

Thanks!

  • What is the problem that you are looking for a solution to? I don't see anything immediately wrong with your example. Yes, three objects all refer to each other - and that's a problem because...? – Igor Tandetnik Aug 30 '14 at 03:58
  • there is a cyclic dependency... as I mentioned in my comment underneath. A -> Lambda, Lambda -> B, B -> A. Which means A or B cannot be destructed. How can I resolve this cyclic dependency? – minibigboss Aug 30 '14 at 04:00
  • 1
    Just holding a reference or pointer to an object doesn't magically prevent the latter from being destroyed. C++ is not Java. – Igor Tandetnik Aug 30 '14 at 04:04
  • how could it be destroyed when both A and B have references to each other? it's because it is C++ it cannot be destroyed... Am I misunderstanding something? Could you elaborate please? – minibigboss Aug 30 '14 at 04:06
  • What makes you believe that holding a reference on an object prevents said object from being destroyed? Wherever you got such an idea? Object lifetime does not in any way depend on whether some other object or objects may or may not refer to it. – Igor Tandetnik Aug 30 '14 at 04:10
  • let me clarify, if you try to destruct A, it will see it has a reference to B, so it will try to destruct B, but B has a reference to first object A (same instance), which means it will try to destruct that A (again)... which means neither A nor B would be destructed. No? That, or a memory leak would occur... – minibigboss Aug 30 '14 at 04:13
  • `it will see it has a reference to B, so it will try to destruct B` The conclusion doesn't follow from the premise. Nothing will "try to destroy" anything else. Anyway, here's a [working example](http://ideone.com/ZaMgR9) – Igor Tandetnik Aug 30 '14 at 04:15
  • Would it be the same if the classes implement IUnknown and are AddRefed? – minibigboss Aug 30 '14 at 04:48
  • @minibigboss That's a completely different deal. Igor is trying to explain that the language doesn't do what you think it does by keeping objects alive because a reference to them exists somewhere. Reference counted COM objects implement the AddRef functionality and do not delete themselves until the reference count falls to zero. The reference counting is entirely handled by code within the class implementation, and not at the language level. The standard C++ equivalent would be a `shared_ptr`. – Praetorian Aug 30 '14 at 07:04
  • If the program otherwise remains unchanged, then yes, it would all still be the same. Just because a class derives from `IUnknown` doesn't magically cause every other class to automatically call `AddRef` on it. In particular, when a lambda captures `this`, it most certainly doesn't `AddRef` it. And of couse, the lambda itself doesn't derive from `IUnknown`. – Igor Tandetnik Aug 30 '14 at 13:20

1 Answers1

0

Even if there is a circular dependency, everything will be deleted because simple references don't prevent anything from deletion. They are just like weak pointers you're talking about.

justanothercoder
  • 1,830
  • 1
  • 16
  • 27
  • What if they are AddRefed? – minibigboss Aug 30 '14 at 05:12
  • I meant that they only point at something. It would be more correct to say that references are similar to plain C pointers. I hope this link will help you http://stackoverflow.com/questions/57483/what-are-the-differences-between-a-pointer-variable-and-a-reference-variable-in – justanothercoder Aug 30 '14 at 05:33
  • Is there any case where a circular dependency can be a problem? Isn't this what weak pointers are all about? – minibigboss Aug 30 '14 at 06:05
  • Circular dependency can be a problem if pointer owns object it refers to. Such pointer as `shared_ptr` for example. – justanothercoder Aug 30 '14 at 07:00
  • Circular dependency can be a problem if two objects refer to each other with pointer that owns object. Then they can't be deleted. Example of pointer that owns object is `std::shared_ptr` – justanothercoder Aug 30 '14 at 07:06