[KPhotoAlbum] Using STL-containers in kphotoalbum code ?

[Shawn Willden]

On Tuesday 01 May 2007 02:56:36 am Jesper K. Pedersen wrote:
> I agree that stl is everywhere.
> 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).

I'm using the STL in the ternary search tree implementation I'm experimenting 
with, to make quick searches quick.  The tree itself is hand-coded, but the 
nodes need sets of ImageInfoPtrs, and I need to be able to perform set 
unions, intersections and differences quickly.  I fiddled for a while with a 
QMap<ImageInfoPtrWrapper, ImageInfoPtrWrapper> where the wrapper provided the 
ordering I wanted, but it didn't do the job very well.  A std::set turned out 
to be significantly faster, more space-efficient and much easier to work 
with.

As Henner said, if you don't have difficulty with Qt collections, you won't 
have a hard time with STL collections either.  They're based on the same 
principles, STL just offers a little more variety of both data structures and 
generic algorithms to operate on them.  Note what the Qt documentation says 
about QMap:

	"QMap is a Qt implementation of an STL-like map container. It 
	can be used in your application if the standard map is not 
	available on all your target platforms."

I'd say the biggest downside of the STL (now that it is widely available) is 
that it does tend to bloat the code when used heavily.  The Qt collections 
are templatized wrappers around non-templated cores, but the STL stuff is 
templated top to bottom, which means that each use of an STL container with 
different types generates a lot of new code.  The other side of that is that 
STL containers offer the compiler lots of optimization opportunities, because 
so much is inlinable.  The STL implementations are also very highly tuned for 
performance.  I tend to favor STL where performance is critical and Qt 
collections otherwise for those reasons.

	Shawn.