[KPhotoAlbum] Using STL-containers in kphotoalbum code ?

[Henner Zeller]

Hi

| 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).
> Well I know, but it is just one more complication, which makes it harder for
> contributers.

Agreed, will try to find a solution without.

> | 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 ?
> Or we could stop using ImageRequest as a pointer, and rework the API to use
> const ImageRequest& instead of ImageRequest*

That is not really a solution. For one, its good that ImageRequest is
a Pointer because it is passed accross thread boundaries: the
requestor passes it to the Manager which works on it and eventually
deletes the request.

The other reason is that you cannot really store references in a map (
/usr/share/qt3/include/qmap.h:667: error: forming reference to
reference type 'ImageManager::ImageRequest&' ).

I think I will go with some kind of a ImageDescriptor here.

cheers,
  -henner

>
> I'm not sure of the consequences of that though.
> |
> | 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.
>
> --
> 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