My pretty printers for map types are very pretty in IDEs but not with gdb's print. There, the tuple sequence is taken for alternating keys and values taking the value part of each tuple.
Created attachment 6538 [details] minimalistic c++ example source
Created attachment 6539 [details] pretty printer implementation
Output for the example is (at line 12): break 12 run p a $1 = A = {[1] = 2}
Created attachment 6540 [details] example displayed in nemiver In contrast to the gdb print, in an IDE using MI the pretty-printers does what it should : pretty.
I don't think there is a gdb bug here. gdb is working as intended. If there is a bug, I think it is in nemiver. IMO nemiver ought to display things differently when the 'map' hint is given. If you don't want the output gdb currently gives, you can just remove the display_hint method.
(In reply to comment #6) > If there is a bug, I think it is in nemiver. it is not only nemiver. Eclipse CDT and Kdevelop4 behave the same. It seems that all those graphical debuggers expect gdb to provide maps as a list (iterable) of key-value tuples. Actually, this is quite reasonable, too. Example [("key1", val1), ("key2", val2)] On the other hand, gdb print on pretty printed maps expects lists (iterables) such as: [("", "key1"), ("", val1), ("", "key2"), ("", val2)] which is definitive less intuitive...
(In reply to comment #7) > (In reply to comment #6) > > If there is a bug, I think it is in nemiver. > > it is not only nemiver. Eclipse CDT and Kdevelop4 behave the same. Personally I think they are all buggy; but in reality the GUIs get to choose how to display. It is up to them. The reason the "map" display hint works the the way it does is because the first element in the tuples in a child list can really only be strings -- but in a "map"-like data structure in the inferior, the key could really be anything, including a complex data structure that itself requires a pretty-printer. When we looked at this, we judged that it was far simpler both internally and for clients to apply special formatting after the fact to rather ordinary varobjs, than it was to try to add a special way for some varobjs to support non-trivial keys. If you don't like how this looks in the CLI, simply do not use the "map" display hint. The kind of output you are asking for is the default.
> When we looked at this, we judged that it was far simpler both internally > and for clients to apply special formatting after the fact to rather > ordinary varobjs, than it was to try to add a special way for some > varobjs to support non-trivial keys. > > If you don't like how this looks in the CLI, simply do not use the "map" > display hint. The kind of output you are asking for is the default. Ok. Then just keep it for your records that there is this discrepancy. Maybe you could complement the documentation about that to have it more clear. (e.g., add a simple example). Locally, I established two (mutual exclusive) modes to choose from.