[KPhotoAlbum] Using STL-containers in kphotoalbum code ?

[Henner Zeller]

Hi,
> I have no strong reasons against STL, except that it is one more thing to
> learn when programming Qt. (Actually I dont personally know much STL, so I
> would have a hard time with STL code).

Its not that complicated. Is very similar what QT already provides
(they claim this is there only to accomodate systems that don't have
STL).

> Are you sure that QMap<ImageRequest*, whatever> doesn't do the job?

Using the pointer as the key would compare the addresses in memory
with the less-than operator instead of comparing the objects. For
this, a custom comparator has to be written - which I don't see a way
in QT.

Another solution I see is to have a pretty small object (called like
ImageDescriptor or ImageKey) that could contain the filename, width x
height, angle (or just the MD5 hash of this tuple) that could even be
used in a normal value set or even as a key for a cache.
Maybe this is more flexible ?

cheers,
  -henner

>
> On Tuesday 01 May 2007 10:26, Henner Zeller wrote:
> | Hi,
> |
> | I haven't seen any use of STL containers in the kphotoalbum code, so I
> | was wondering if it was 'allowed' ? Are there reasons only to use the
> | QT-containers ?
> | (Yes, STL really is available everywhere!)
> |
> | The reasons why I am asking is because I need a set of elements, but
> | don't want to store the values (unecessary call to the copy
> | constructor), but only the pointers to it; the way you would do this
> | using the STL would be to write a comparator that takes the pointers
> | but compares the instances:
> |
> | struct FooPtrLessThan
> | {
> |   bool operator()(const Foo* a, const Foo *b) const
> |   {
> |     return *a < *b;
> |   }
> | };
> |
> | I don't see a way to do this with QMap or other containers in QT.
> | Disclaimer: I haven't done any QT/KDE programming since KDE 1.1 so I
> | might have missed something and happy to learn how this can be done
> | using the existing containers.
> |
> | Reason for this all: There is a check in
> | ImageManager::RequestQueue::addRequest() that looks if an ImageRequest
> | to be added is already in the pending list. Since this is a linear
> | search, adding n elements is an O(n^2) operation - which makes showing
> | thumbnails on a big screen _very_ slow. Having the pending elements in
> | a set with the values being compared would help a lot here.
> |
> | -henner
> | _______________________________________________
> | KPhotoAlbum mailing list
> | KPhotoAlbum at kdab.net
> | http://mail.kdab.net/mailman/listinfo/kphotoalbum
>
> --
> Having trouble finding a given image in your collection containing
> thousands of images?
>
> http://www.kphotoalbum.org might be the answer.
>


-- 
Henner Zeller | h.zeller at acm.org
Bücher kaufen und freie Software fördern | http://bookzilla.de