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

[Werner Trobin]

On Monday 28 April 2003 20:47, George Staikos wrote:
> On Monday 28 April 2003 14:40, Werner Trobin wrote:
> > >    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.
> 
>    So why not implement this in kde-qt-addons or something like that if TT 
> can't accept that?  I am fully aware of how STL works:

#1 You were asking for an example, I gave one :-)  (a better example might 
have been QTL's we-need-a-default-constructor foible)

#2 I know that you program both QTL and STL, see #1. I didn't intend to offend 
you or anyone else.

#3 I wonder how it would be less "bloat" to implement it again and again (in 
kde-qt-addons), instead of using the perfectly tested std::vector?

Ciao,
Werner