From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-56282-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 13067 invoked by alias); 23 May 2008 14:33:03 -0000
Received: (qmail 13022 invoked by uid 22791); 23 May 2008 14:33:01 -0000
X-Spam-Check-By: sourceware.org
Received: from mailman.allo-creation.fr (HELO ns39154.ovh.net) (91.121.20.133)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 23 May 2008 14:32:42 +0000
Received: (qmail 32103 invoked by uid 508); 23 May 2008 14:53:29 -0000
Received: from unknown (HELO ?192.168.1.4?) (82.226.112.216)   by 87-98-251-24.ovh.net with SMTP; 23 May 2008 14:53:29 -0000
Subject: Re: GDB C plugin system, and STL container viewer as an example
From: Vincent Benony <vbenony@nordnet.fr>
To: Vladimir Prus <vladimir@codesourcery.com>
Cc: gdb-patches@sources.redhat.com
In-Reply-To:  <g16jrk$3r6$1@ger.gmane.org>
References:  <1211535909.8253.16.camel@bsr-desktop> 	 <g16jrk$3r6$1@ger.gmane.org>
Content-Type: text/plain; charset=utf-8
Date: Fri, 23 May 2008 19:59:00 -0000
Message-Id: <1211553158.6621.6.camel@bsr-desktop>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.1
Content-Transfer-Encoding: 8bit
X-IsSubscribed: yes
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2008-05/txt/msg00683.txt.bz2

> I don't see how you report that fact that the number of children of a
> varobj has changed. Without that, I'm not sure how useful MI display
> of vectors is. Am I missing something?
> 
> - Volodya

this is done by lines 1157 to 1166 of varobj.c


      if (plugins_type_handled(varobj_get_gdb_type(*varp)))
      {
          int new_childs = plugins_get_num_children(*varp);
          if (new_childs != (*varp)->num_children)
          {
              (*varp)->num_children = new_childs;
              (*varp)->children = varobj_list_children (*varp);
              VEC_safe_push (varobj_p, result, *varp);
          }
      }


I evaluate the number of children at each update, and I compare with the
current number of childs stored in the varobj structure, if different,
object is added to update list.

It seems to work well into KDevelop and Insight/GDB, ie if I step in my
source code, I can see children items beeing added at each push_back.

Only Eclipse/CDT has a problem handling a vector going from 0 to 1
child (child is not displayed, but Eclipse say that number of children
has changed, displaying the correct number ; seems like an Eclipse bug),
but it works when going from 1 to 2 children, or more...