[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: [PATCH 04/11] mfplat: Implement IMFAttributes::{SetItem, GetItem}.
From:       Nikolay Sivov <nsivov () codeweavers ! com>
Date:       2018-12-29 17:16:59
Message-ID: dd1d1dd6-1f69-4e74-1550-2123899ec6f1 () codeweavers ! com
[Download RAW message or body]

On 12/29/18 6:50 PM, Jactry Zeng wrote:

> Hi Nikolay,
>
> Thanks for review!
>
> Nikolay Sivov <nsivov@codeweavers.com> 于2018年12月29日周六 上午1:09写道：
>> On 12/28/18 6:42 PM, Jactry Zeng wrote:
>>
>>> +struct mfattribute
>>> +{
>>> +    struct list entry;
>>> +    GUID key;
>>> +    PROPVARIANT value;
>>> +};
>>> +
>>>    typedef struct _mfattributes
>>>    {
>>>        IMFAttributes IMFAttributes_iface;
>>>        LONG ref;
>>> +    CRITICAL_SECTION lock;
>>> +    struct list attributes;
>>>    } mfattributes;
>> Also GetItemByIndex() suggests array would be more appropriate.
>>
> Please correct me if I misunderstand anything.
> Since it has IMFAttributes::DeleteItem which can delete any attribute
> from that list, it seems that list can make thing more simple?
> Or it will need to reorder the array every time an attribute is deleted.
>
Ideally it should be a hash table I suppose, additionally indexed to 
make GetItemByIndex() work, assuming it maintains a stable order when 
you add/remove items.

If it's not stable and then it would be just a hash table, choosing 
between list and array in this case depends on GetItemByIndex() 
behavior, and "normal" use case, e.g. if applications don't normally 
remove attributes, and index is stable then array would be better.




[prev in list] [next in list] [prev in thread] [next in thread]