From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6170 invoked by alias); 20 Jul 2012 21:20:42 -0000 Received: (qmail 6162 invoked by uid 22791); 20 Jul 2012 21:20:41 -0000 X-SWARE-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-we0-f169.google.com (HELO mail-we0-f169.google.com) (74.125.82.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 20 Jul 2012 21:20:26 +0000 Received: by weys10 with SMTP id s10so3549318wey.0 for ; Fri, 20 Jul 2012 14:20:25 -0700 (PDT) Received: by 10.180.81.138 with SMTP id a10mr17659359wiy.7.1342819224732; Fri, 20 Jul 2012 14:20:24 -0700 (PDT) Received: from [10.0.0.3] (d83-191-103-145.cust.tele2.at. [83.191.103.145]) by mx.google.com with ESMTPS id o2sm19081419wiz.11.2012.07.20.14.20.23 (version=SSLv3 cipher=OTHER); Fri, 20 Jul 2012 14:20:23 -0700 (PDT) Message-ID: <5009CB96.9040007@googlemail.com> Date: Fri, 20 Jul 2012 21:20:00 -0000 From: Oliver Buchtala User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Tom Tromey CC: gdb@sourceware.org Subject: Re: Inconsistency between results of pretty-printing children References: <50092D6B.3040103@googlemail.com> <87629iusci.fsf@fleche.redhat.com> <5009B73B.2030702@googlemail.com> <87txx2tcls.fsf@fleche.redhat.com> In-Reply-To: <87txx2tcls.fsf@fleche.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-07/txt/msg00067.txt.bz2 On 20.07.2012 22:13, Tom Tromey wrote: >>>>>> "Oliver" == Oliver Buchtala writes: > Oliver> here the doc: > Oliver> http://sourceware.org/gdb/onlinedocs/gdb/Pretty-Printing-API.html > Oliver> under display_hint "map" > > Ok, I see. > > In the 'map' case, each item returned by the 'children' iterator must > still be a 2-tuple of the form (NAME VALUE). > > What 'map' means is that the first item fetched from the iterator is > considered to be a key in the map, and the second item fetched from the > iterator is considered to be the corresponding value. Then the 3rd item > is a key again, the 4th is a value again, and so on. > > In the CLI the NAME parts are omitted when printing, in this case, just > because it makes the output prettier. > > In MI, nothing changes -- the hint is emitted and the MI client is > expected to take whatever action it thinks appropriate. > > > Here's an abbreviated example from the libstdc++ test suite: > > std::map mp; > mp["zardoz"] = 23; > // { dg-final { note-test mp {std::map with 1 elements = {["zardoz"] = 23}} } } > > That last line means that 'print mp' here should show: > > std::map with 1 elements = {["zardoz"] = 23} > > If you dig into the libstdc++ StdMapPrinter code you see: > > def next(self): > if self.count % 2 == 0: > n = self.rbiter.next() > n = n.cast(self.type).dereference()['_M_value_field'] > self.pair = n > item = n['first'] > else: > item = self.pair['second'] > result = ('[%d]' % self.count, item) > self.count = self.count + 1 > return result > > So in the example above it returns a list like > > [ ('[0]', '"zardoz"'), ('[1]', 23) ] > > > > My question for you is: how can we improve the documentation to make > this more clear? > > Right now they read: > > @item map > Indicate that the object being printed is ``map-like'', and that the > children of this value can be assumed to alternate between keys and > values. > > > Tom Ok... I think I understand now... but it is definitely not intuitive to provide keys that are not used at all. At least, we could enhance the documentation so that this is clear. Just by example... that's enough. You can close the issue I created... (with a bit of dislike of mine for that "hack" ;) ) Thanks, Oliver