qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH 04/29] Introduce QDict


From: Luiz Capitulino
Subject: [Qemu-devel] Re: [PATCH 04/29] Introduce QDict
Date: Thu, 20 Aug 2009 12:08:28 -0300

On Thu, 20 Aug 2009 17:07:25 +0300
Avi Kivity <address@hidden> wrote:

> On 08/20/2009 04:57 PM, Luiz Capitulino wrote:
> > On Thu, 20 Aug 2009 10:57:54 +0300
> > Avi Kivity<address@hidden>  wrote:
> >
> >    
> >> On 08/20/2009 02:07 AM, Luiz Capitulino wrote:
> >>      
> >>> QDict is a high-level dictionary data type that can be used to store a
> >>> collection of QObjects. A unique key is associated with only one
> >>> QObject.
> >>>
> >>> The following functions are available:
> >>>
> >>> - qdict_new()    Create a new dictionary
> >>> - qdict_add()    Add a new 'key:object' pair
> >>>
> >>>        
> >> qdict_put() is both symmetrical with qdict_get(), and also conveys the
> >> fact that you can replace an existing key/value.
> >>      
> >   Would it be useful in the current Monitor code? If so, how?
> >    
> 
> The current code, no, but once we read qdicts from the monitor, you need 
> to be able to handle { a: 1, a: 2 }.

 qdict_add() will refuse to add an existing key, but I can change
it to replace instead.

 Would this be enough?

> >>> + */
> >>> +int qdict_get_int(const QDict *qdict, const char *key)
> >>> +{
> >>> +    QObject *obj = qdict_get_obj(qdict, key, QTYPE_QINT);
> >>> +    return qint_to_int(qobject_to_qint(obj));
> >>> +}
> >>>
> >>>        
> >> This assumption does not hold if the dict came from a user.
> >>      
> >   Then the user has to know what he or she is doing. :)
> >    
> 
> They don't, as a rule.

 That's why there's an assert() there. :)

> >   The problem with high-level functions that receive a QObject
> > but return a plain int is: what do you return if QObject is
> > not an QInt?
> >    
> 
> Pass a default value to return.

 Looks a good solution, although I think both cases are useful.

 For most handlers, for example, the monitor code _must_ push
the key specified in qemu-monitor.hx into the dictionary. Not
doing this is a bug.

 But we also support optional keys, which may or may not be
pushed into the dictionary.

 We need two functions then and this also applies to QString.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]