From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31176 invoked by alias); 11 May 2006 11:24:28 -0000 Received: (qmail 31029 invoked by uid 22791); 11 May 2006 11:24:18 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 11 May 2006 11:24:10 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1Fe9Ga-0001sG-VL for gdb@sources.redhat.com; Thu, 11 May 2006 15:23:38 +0400 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1Fe9GP-0001pl-7q; Thu, 11 May 2006 15:23:25 +0400 From: Vladimir Prus To: Bob Rossi Subject: Re: asynchronous MI output commands Date: Thu, 11 May 2006 12:50:00 -0000 User-Agent: KMail/1.7.2 Cc: Alain Magloire , gdb@sources.redhat.com References: <3518719F06577C4F85DA618E3C37AB9105359CCA@nimbus.ott.qnx.com> <200605111447.37126.ghost@cs.msu.su> <20060511105531.GG3727@brasko.net> In-Reply-To: <20060511105531.GG3727@brasko.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605111523.24678.ghost@cs.msu.su> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00136.txt.bz2 On Thursday 11 May 2006 14:55, Bob Rossi wrote: > > > > const GDBMI::Value& children = r["children"]; > > > > > > > > for (unsigned i = 0; i < children.size(); ++i) > > > > { > > > > QString exp = children[i]["exp"].literal(); > > > > > > > > > > > > If you have specific structures for each response this won't be very > > > > much simpler. > > > > > > Sorry, I've described this before, but apparently not good enough. I > > > definatly can create the abstract parse tree with out knowing the input > > > command. However, then I want to create C data structures for each > > > MI output. > > > > Why? With C data structures, the above frontend code will be only > > marginally simpler. > > I don't believe that to be the case at all. Look at the C data structure > code I have for the -break-list data structure. If a GUI had to use this I > think they would be happy. So, instead of say: bp["number"].toInt() I'd write: bp.number ? Well, that's what I call "marginally better". It's better, but not likely to make big practical difference. Also, you propose C interface, so is not directly usable in frontend written in C++. Such frontend will likely to have it's own class for breakpoint, and would have to convert from your structure to that class. I guess if you want to make MI parser for your own use, any approach is fine. But if you want to make some kind of "standard" MI parser for other frontends to use, I'm not sure that providing such pre-made structures will be a selling point. > Look at what I had to do to get the breakpoint structure populated. I > don't consider this even close to the same complexity as above. What do you mean as "above" and why having more complex code is a good thing? > I do > know that I have some code duplicated that could be in a function, and > some other cleanups, but I still think it's far more difficult. I think the code you've presented indeed has too much copy-paste. For example: else if (strcmp (result_ptr->variable, "addr") == 0) { if (result_ptr->value->value_choice == GDBMI_CSTRING) { if (convert_cstring (result_ptr->value->option.cstring, &ptr->address) == -1) { fprintf (stderr, "%s:%d\n", __FILE__, __LINE__); return -1; } } } is a pattern that repeats for many of fields. While in my interface, you'd call: bp["addr"].literal() to get exactly same effect. Except that in your code, no error is emitted when "addr" field is not of string type ;-) Maybe if you provide functions 'get_literal' and 'get_integer' and 'get_bool_yn', the size of code can be reduced considerably. - Volodya