Kristian D'Amato
Kristian D'Amato

Reputation: 4046

Strange VS2013 bug? Or programmer induced disease?

I have a GameObject class that inherits from Object. Stepping in both their constructors has gone crazy, but the objects are created without a problem. Before someone asks, I'm on a debug build. Let me show you:

Edit Since people complained, I will post the actual code, not images.

GameObject::GameObject(string name) : Object(name)
{
    // ...
}

Component* GameObject::AddComponent(SharedPtrComponent component)
{
    if (find(components.begin(), components.end(), component) == components.end())
    {
        components.push_back(component);
        return component.get();
    }

    return nullptr;
}

After the program executes the first line of the GameObject constructor (i.e. the Object initialization), it skips to the empty line between the brace and return nullptr in AddComponent.

What's going on?

PS. I tried this on both express and ultimate versions. Exact same stepping sequence. And I tried cleaning etc. The Object constructor is acting up likewise. Mm.

Update: Ok, maybe this works: here's a minimal project which still exhibits the strange stepping: VS2013 project

Upvotes: 0

Views: 187

Answers (2)

ixSci
ixSci

Reputation: 13718

Ok, I believe I understand what is going on here. In short: it is a visual bug in MSVS debugger.

Let's find out what is going on: first you create your GameObject which consists of the following steps: call parent ctor(Object) and call initializers and/or inline initializers. You don't have initializers but you have inline initializer GameObject* parent = nullptr;

And that is exactly why debugger goes visually crazy it has to execute initializers which is not right here but in the header instead. I'm not sure why it has this glitch but if you remove inline initializers it will be gone. I suggest to file a bug to the Visual Studio team. It is only a visual bug but still a bug.

Upvotes: 2

Martin Ba
Martin Ba

Reputation: 38971

If you have problems when stepping through the code in the debugger, it is often a good idea to switch to disassembly view (ALT + 8) and step through there.

You do not have to understand much of the assembly. Just look for call instructions and the like. Note that if you step into another function (from the disassembly view call) with F11, you can then switch back to the actual source code (if you have it).

Upvotes: 0

Related Questions