Community
Participate
Working Groups
From the CDT dev list: http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg13534.html In the variables view, when showing a variable, only the declared type is shown and dealt with, instead of the implemented type. class Client { public: virtual ~Client() {} }; class SpecificClient : public Client { public: SpecificClient(int i) {mFive=i;} virtual ~SpecificClient() {}; private: int mFive; }; int main() { Client *p = new SpecificClient(5); return 0; } In this case, variable 'p', will only be shown as a pointer, and will not be expandable. To be able to see the member, one would have to cast it to (SpecificClient*). In the JDT, the type is immediately shown to be SpecificClient. Apparently, GDB does know this information as shown by the "set print object on" command.
Yeah, it'd be great if we could get this exposed in the variables view. Even if GDB doesn't implement an easy way to retrieve this information any time soon, we should enhance the expression view API.
I saw this issue hasn't been updated for more than 1 year. I am using CDT on a very large project which heavily uses polymorphism. Is there a workaround for this issue if a fix is not available?
I think this is a good bug to get fixed. I suggest you vote for it. The workaround, although not very good, is to cast your variable manually. Right-click on it and choose 'cast-to-type'.
(In reply to comment #3) > I think this is a good bug to get fixed. I suggest you vote for it. > The workaround, although not very good, is to cast your variable manually. > Right-click on it and choose 'cast-to-type'. Another workaround could be to use the python pretty printer infrastructure of gdb: register a pretty printer for all pointer types (or the ones you are interested in). In the pretty printer you can find out via rtti (gdb 7.3 has a method method for gdb.Value) what the implementation type is and return the casted value. Haven't tried it, though;-)
(In reply to comment #3) > I think this is a good bug to get fixed. How would this fix look like? Ideally the gdb guys would accomodate this in their MI varobjs, similar to what they do in their command line interface. But from what I perceive, they will not do it.
(In reply to comment #5) > (In reply to comment #3) > > I think this is a good bug to get fixed. > How would this fix look like? If we figure out what is the most specific type, we can maybe automatically cast to it. -var-create --thread 1 --frame 0 - * "(SpecificClient *)(p)" I'm not sure if we should do it directly in the MIVariableManager or re-use the "Cast to type" feature that we have. We can start with the re-use because it may be simpler to implement.
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #3) > > > I think this is a good bug to get fixed. > > How would this fix look like? > If we figure out what is the most specific type, we can maybe automatically > cast to it. > -var-create --thread 1 --frame 0 - * "(SpecificClient *)(p)" > I'm not sure if we should do it directly in the MIVariableManager or re-use the > "Cast to type" feature that we have. We can start with the re-use because it > may be simpler to implement. I fear I broke it, won't work with children of pretty printers:-(
