[Development] Dropping QT_NO_STL (was: The future of QtAlgorithms)

[lars.knoll at nokia.com]

Guess I should give my $0.02 as well ;-)

I'm perfectly fine with dropping -no-stl. As already explained in this
thread, we need STL (or a subset of it) anyways on embedded systems (due
to V8 and WebKit). On desktop systems -no-stl doesn't make any sense
anyway.

Now the main point is about decent guidelines on where and how we use the
STL. Thiago had a pretty good first list and with a little tuning we might
get to a good policy here.

I think we need to be careful and try to avoid adding STL dependencies to
our public headers. Ideally, we get away with forward declarations of STL
types for interoperability.

In implementations, we can use whatever makes most sense from the set
agreed upon (with some care, so we keep our code readable and
maintainable). So if std::vector is better suited to a certain task than
QVector, let's just use it.

Cheers,
Lars


On 1/31/12 12:12 PM, "ext Thiago Macieira" <thiago.macieira at intel.com>
wrote:

>On Tuesday, 31 de January de 2012 11.38.05, André Pönitz wrote:
>> > I'd like our containers to be good enough for that, to be honest. And
>> > avoid
>> > subtle mistakes if the behaviour differs.
>> 
>> The problem is that QVector is _not_ "good enough" for some cases,
>>mostly
>> due to the sharing overhead.
>> 
>> Using std::vector in  _p.h or .cpp where it makes sense seems perfectly
>>fine
>> to me, (as would tackling the sharing problem)
>
>Tackling the sharing problem is something that João wanted to do.
>
>> > Just avoid "template bloat": out-of-line copies of identical code
>>because
>> > the compiler can't figure out two functions do the same. It's hard to
>> > measure.
>
>> But it _is_ measurable, and when you do it you'll come to the result
>>that
>> straightforward QVector using code (i.e. using at() or even operator[]
>> instead of .data() plus pointer[index]) expands to significantly more
>>code
>> than std::vector. An awful lot of std::vector code expands to a handful
>> instructions while QVector access has all kind of indirections and
>> conditional execution.
>
>One of the conditionals must be the check for the refcount. Having
>removed the 
>volatile now, one would expect that the compiler knows it hasn't changed
>across the two calls.
>
>Still, doing benchmarks now is pointless since there's a major rewrite
>pending 
>from João's "containers" branch. Once that is in, I'd like to spend some
>time 
>inspecting the code generated and see how to improve it. I'll repeat your
>tests once that is in.
>
>> So QVector has an advantage when it is copied, but loses by
>> a factor of almost two in local access in this case.
>> 
>> I argue that local access happens more often than copying,
>> so QVector is optimizing for the wrong use case.
>
>We need to fix that then.
>
>> Of course you can tweak the code at get better results, at the expense
>> of readability and convenience, and not all access pattern are _that_
>> bad. But the bottom line stays.
>
>Indeed. Reading STL container code is *not* fun. Not only is the coding
>convention ugly by our standards, it goes all over the place.
>
>> If you/we want to have a "good enough" replacement with sane syntax
>> and all the Qt container convenience, drop the sharing from QVector.
>> 
>> As the change would be essentially source compatible we do have
>> the chance to fix it in Qt 5.
>
>See above.
>
>-- 
>Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
>     Intel Sweden AB - Registration Number: 556189-6027
>     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
>_______________________________________________
>Development mailing list
>Development at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development