[Digikam-devel] QList <->QVector

Francesco Riosa francesco at pnpitalia.it
Sun Aug 28 23:00:59 BST 2011


I don't promise anything but I want to have my split database work for 
the earliest times after 2.1.0 release, hopefully for sunday. It does 
touch mostly database code tough.


On 08/28/11 18:05, Gilles Caulier wrote:
> Forget to said that i will apply patches just after 2.1.0 release.
>
> Gilles
>
> 2011/8/28 Gilles Caulier<caulier.gilles at gmail.com>:
>> Andi,
>>
>> Before to patch in this way, i sugest to way 2.1.0 release planed next sunday.
>>
>> On my computer, i currently review 2 big patches :
>>
>> https://bugs.kde.org/show_bug.cgi?id=155374
>>
>> .. which will be complex to adapt because they touch a lots of parts
>> in digiKam...
>>
>> Gilles
>>
>> 2011/8/28 Marcel Wiesweg<marcel.wiesweg at gmx.de>:
>>>
>>>
>>>> Maybe we should consider changing QList to QVector in digiKam's code? With
>>>> the patch in the above link Qt will throw a warning when an inefficient
>>>> type is used in the QList container.
>>>
>>> QList is much more convenient IMO. Most importantly, Qt API usually takes
>>> QLists and not QVectors, and a conversion may render any won time to a loss.
>>>
>>> I suggest therefore only to think of conversion if profiling proofs that QList
>>> usage is a problem (*)
>>>
>>> There are places in digikam code where this has already been done: Most
>>> importantly, in DigikamKCategorizedView, and in ImageFilterModel
>>>
>>> (*) For our needs, QList will get problematic if the stored object is larger
>>> than a pointer, and or not movable. In profiling, the construction and
>>> destruction of the object will then become noticeable. Unfortunately, two
>>> important and extensively used classes are problematic in this regard:
>>> QModelIndex and QVariant. But Qt API uses QList everywhere for those, so
>>> QVector is often not an option.
>>>
>>> Marcel




More information about the Digikam-devel mailing list