Why isn't my implementation of a virtual function being called in this case?

Question

I have access to an interface, that implements the virtual method iObjectManager::getTile(const Course::ObjectId &id) = 0. I've reimplemented said method in an inherited class ObjectManager:public Course::iObjectManager as follows:

std::shared_ptr<Course::TileBase> getTile(const Course::ObjectId &id) override;

std::shared_ptr<Course::TileBase> ObjectManager::getTile(const Course::ObjectId &id)
{
  qDebug() << "Looking for tile based on ID...\n";
  for (unsigned i = 0; i < getMapSize(); i++) {
    for (unsigned j = 0; j < getMapSize(); j++) {
      std::shared_ptr<BoardPiece> tile = getGameMap().at(i).at(j);
      if (tile->ID == id) {
        qDebug() << "Tile found.\n";
        return std::move(tile);
      }
    }
  }
  qDebug() << "No tile with given index...\n";
  return nullptr;
}

The issue arises, when the course side code calls getTile: nothing happens. The calls to qDebug are not made and nothing is printed. Why would the function fail to get called (or the one lacking an implementation get called) even though I've implemented the function properly (I think)?

The functio is called as follows:

tile = lockObjectManager()->getTile(ID);

where lockObjectManager is defined as

std::shared_ptr<iObjectManager> GameObject::lockObjectManager() const
{
    std::shared_ptr<iObjectManager> handler = OBJECTMANAGER.lock();
    Q_ASSERT(handler);
    return handler;
}

Edit

I've just discovered, that my ObjectManager is destroyed right after its initialization. This is weird, as I have it set as a member of my MainWindow right at the start of its construction, but it is also given to my GameEventHandler as an initialization parameter, and the gameEventHandler does not die either (based on my qDebugging):

GOManager_ = std::make_shared<ObjectManager>(playerAges_);
GEHandler_ = std::make_shared<GameEventHandler>(GOManager_);

Either the main window of the eventhandler (or both) should be keeping the objectmanager alive, but they are not... Is this because I've not provided an assignment operator, as described here?

There's not enough context to say anything, so please try to create a [mcve] to show us. Perhaps refresh about [how to ask good questions](http://stackoverflow.com/help/how-to-ask), as well as [this question checklist](https://codeblog.jonskeet.uk/2012/11/24/stack-overflow-question-checklist/). — Some programmer dude, Nov 27 '19 at 20:12
It doesn't look like you call getTile at all, in this code. I'm assuming wherever you do call it, use used a syntax that specifies which class to call it on, rather than virtual lookup. — Kenny Ostrom, Nov 27 '19 at 20:13
Double check that in the base class, the `getTile()` method has the `virtual` keyword in its declaration, and that its signature matches the signature of your subclass-method *exactly* (including with respect to the presence/absence of a `const` keyword at the end of the signature) — Jeremy Friesner, Nov 27 '19 at 20:13
"The calls to qDebug are not made and nothing is printed" - are you sure the `qDebug` output is going where you expect it to? Your IDE may be intercepting it, it may have been redirected to a file, the output may be going to `std::cerr` and you only check `std::cout` (or vice versa). Lots of things could be happening that don't all mean that the code is not running. — Jesper Juhl, Nov 27 '19 at 20:16
What object are you calling `getTile` on? Could you be [slicing](https://stackoverflow.com/questions/274626/what-is-object-slicing) your original object? — Miles Budnek, Nov 27 '19 at 20:17
@JeremyFriesner The `virtual` keyword is there, and there is no `const` at the end of the signature. To my eyes, the declarations are exactly the same, no includign the class specifier (`iObjectManager` vs `ObjectManager`). — sesodesa, Nov 27 '19 at 20:17
Could you add your declaration of `tile` and `lockObjectManager` along with whatever value you set them to? — , Nov 27 '19 at 20:52

score 1 · Answer 1 · answered Nov 27 '19 at 20:29

1

Make sure OBJECTMANAGER.lock() is returning an instance of the derived ObjectManager class. If it is returning iObjectManager(), it will call its base version of getTile(), not the overloaded one.

answered Nov 27 '19 at 20:29

Saisai3396

311
1
8

This might be it. I've just discovered, that my Objectmanager is destroiyed right after its initialization. For some reason my main window is not keeping it alive, even though the `ObjectManager` is set as its member variable right at the initialization of said window. – sesodesa Nov 28 '19 at 09:00

Why isn't my implementation of a virtual function being called in this case?

Edit

1 Answers1