[Qgis-developer] STL vs. Qt containers

[Mateusz Loskot]

Martin Dobias wrote:
> On 10/27/06, Gavin Macaulay <g.macaulay at niwa.co.nz> wrote:
>>
>> I prefer the STL containers. I find them to have a more consistent
>> interface than the Qt ones, although with Qt4 most, if not all, of the
>> containers work with STL algorithms and have STL-like functions.
> 
> This might be a matter of taste. What do you think is more consistent in
> STL?

Marting,

Generally, I'd agree ;-)

> When I compare the usage of containers between Qt and STL, Qt ones can
> have much nicer syntax.

I can't agree

> -- STL --
> 
> std::list<int> lst;
> ...
> std::list<int>::iterator it;
> for (it = lst.begin(); it != lst.end(); it++)
-----------------------------------------^^^^^^

It's a bad idea to use post-increment with iterators!

> {
>  std:: cout << *it << std::endl;
> }

First, in this particular example following should be preferred
for best performance and optimization:

std::list<int>::const_iterator end = lst.end();
for (std::list<int>::const_iterator it = lst.begin(); it != end; ++it)


Finally, what's simpler and less error prone comparing to this?

std::copy(lst.begin(), lst.end(),
          std::ostream_iterator<int>(std::cout, "\n"));

> -- Qt --
> 
> QList<int> lst;
> ...
> QListIterator<int> it( lst );
> while ( it.hasNext() )
> {
>  std::cout << it.next() << std::endl;
> }


Unfortunately, after I've read Trolltech's doc about their containers, I
have to say there is quite much of FUD.
Second, even they point that Java iterators are expected to be slower:

"They are more convenient to use than the STL-style iterators, at the
price of being slightly less efficient"

For me, the FUD are statements like "more convenient to use".
Why Trolls compare their containers with STL containers only?
It's a wrong approach from the basis.

STL, a part of C++ Standard Library, is *not* only a set of containers!
It's very *incorrect* to talk only about STL containers and how they
are cool or not.
STL is the _whole_system_ of types and operations:
container + iterators + algorithms + allocators.
STL design, concepts, interface and performance should be analyzed
including all these 4 types of STL elements.

Why STL iterators interface is defined as it is?
Because iterators are indirection layer that makes it possible to
operate on containers using common algorithms definition.
The main idea here is to provide deep interface consistency with
very good performance.

Second, using STL you can easily "plug & play" with Boost libraries.
For example, latest TR1 [1] include many of features from Boost,
with new containers like fixed-size array, unordered associative
containers and tuples, and - thanks to STL interface design
principles - coders can just take and use these new elements,
without changing their habits or learning it again.

If Trolls are going to support Java-like and STL-like interface together
with all Java-like utils (algorithms, etc.) and STL-like (explained
above), I only can wish them luck, but IMHO this will make their
containers API bloated, so easily misused.

One controversial question comes to my mind, why not to switch to Java
completely if STL interface is considered as hard and error prone?
I'm sorry, but it's hard to understand for me.

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf
BTW, TR1 libraries are available in GCC, std::tr1 namespace.

> But my primary idea is to decide which type of containers to adapt (or
> at least which type for public API), because now we use both STL and

I agree, consistency is important.

Cheers
-- 
Mateusz Loskot
http://mateusz.loskot.net