[KPhotoAlbum] Using STL-containers in kphotoalbum code ?

[Jesper K. Pedersen]

On Tuesday 01 May 2007 12:13, Henner Zeller wrote:
| 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&' ).
Well sure, I wanted to store the instance in the map.

| I think I will go with some kind of a ImageDescriptor here.
If you do so, please add doxygen comment describing the class.

|
| 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.

-- 
Having trouble finding a given image in your collection containing
thousands of images?

http://www.kphotoalbum.org might be the answer.