This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug mi/13393] There is no way to access runtime type of C++variable via MI (using RTTI)


http://sourceware.org/bugzilla/show_bug.cgi?id=13393

--- Comment #6 from Andre Poenitz <andre.poenitz at nokia dot com> 2011-11-09 13:17:35 UTC ---
I've been using the MI/varobj approach for quite some time (and unfortunately
still have to on Mac) and it simply does not scale beyond simple scenarios
like, say dumping a std::vector or std::map or such. For more complex displays
it is far too inflexible and requires too many roundtrips translating directly
into "waiting time" for the user. It's strictly no fun to work with, both from
a frontend implementor's and an end user's perspective. An "all python"
approach for data display is much more flexible, faster, and easier to extend
for users.

Also, gdb/MI in general has essentially been unmaintained for a more than year
now (yes, I am aware of the added breakpoint notifications last April...),
whereas gdb/Python has improved a lot in the meantime. So even assuming that
the general MI/varobj approach would feasible in general (which I honestly
doubt, e.g. the question which kind of data is "needed" in a response can never
be answered in a frontend agnostic way and just spawned endless discussions
with no tangible outcome in the past) I don't see evidence that gdb/MI could
catch up to where gdb/Python already is in any interesting time frame. -- --
It's dead, Jim ;-|

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]