Jump to content
  • Advertisement
Sign in to follow this  
irreversible

Natvis: inspecting a static member variable of a derived class?

This topic is 528 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

The title says it all really. I'm on VS2013 and am beginning to think this is a bug. In particular, even the following code (which is illustrative in its functionality) gives me the class name from the base class (gsl::window) instead of derivedwnd:

 

    <Type Name="gsl::window">
        <Expand>
      <Item Name="[class]">((derivedwnd*)this)->_className,na</Item>

        </Expand>
    </Type>

 

Both classes contain a static _className member that is returned via an overloaded GetClass() procedure. Since Natvis can't invoke functions, I need to access the data member directly. However I can't find any information on this particular situation.

 

Can anyone confirm this a bug/feature of Natvis or know of a workaround?

Share this post


Link to post
Share on other sites
Advertisement

Try something like:

((derivedwnd*)this)->derivedwnd::_className

 

Thanks for the input. Unfortunately it doesn't work. And even if it did, it wouldn't solve the real problem, which I probably left a bit unclear: I don't actually know the type of the derived class.

 

Basically, I want to write a rule for all classes derived from gsl::window (which should automatically be the case), but retrieve _className stored statically in each derived type.

Share this post


Link to post
Share on other sites
The short answer is I don't think you can do that.

In order to use a member of a derived-class object, the debugger has to know what class to interpret the memory as. It can do this in limited situations by inspecting the vtable pointer of the object itself, but I'm not aware of a way to turn that back into something that natvis can use.

If you have some weak guarantee like "_className is always the 0th member of the object and thus exists immediately after the vtable pointer" you can find it by doing the pointer arithmetic by hand, but if you have multiple base classes this falls apart very quickly.

Share this post


Link to post
Share on other sites

The short answer is I don't think you can do that.

In order to use a member of a derived-class object, the debugger has to know what class to interpret the memory as. It can do this in limited situations by inspecting the vtable pointer of the object itself, but I'm not aware of a way to turn that back into something that natvis can use.

If you have some weak guarantee like "_className is always the 0th member of the object and thus exists immediately after the vtable pointer" you can find it by doing the pointer arithmetic by hand, but if you have multiple base classes this falls apart very quickly.

 

 

Yeah, I figured as much. Thanks for confirming.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!