Reason for -no-stl in qt-copy configure recommendation?

[Werner Trobin]

On Monday 28 April 2003 20:19, George Staikos wrote:

[...STL ramblings...]

> > >    If you allow people to use STL, you have no right to deny them to
> > > reimplement, say std::vector, their own way and use that.  Then you 
could
> > > have a different class with a different interface in every app/library!
> >
> > I don't understand. IMHO it's something very different to say you can't 
use
> > a part of the language (here: STL) or don't reimplement stuff that already
> > exists as part of the language (STL) or in our base library (QTL).
> 
>    We already have std::vector equivalence in Qt.  What you are saying is 
that 
> only things that cannot be done with Qt may be done with STL?  I will be 
> interested to see this.

Okay, this is the first example that came to my mind :-)

Suppose you have a QValueVector in your FooGadget class and would like to call 
some external library function (e.g. to perform a highly optimized assembler 
FFT of the sequence in your vector), taking a plain vanilla C array. You 
can't just call the method with your QValueVector, as you don't have any 
guarantees concerning the layout of the internal data.

Using a std::vector solves the problem, as std::vector is guraranteed to keep 
the internal data in an array. You just have to pass the pointer to the first 
element in the vector (and probably the size as separate parameter) and 
you're done. Piece of cake.

Ciao,
Werner