QTL and erase()

[tuli]

Hi,

I am currently porting c++ code from STL to QTL (std::vector to QVector). QTL claims to be largely compatible to the STL - and it is indeed.
The one STL method we frequently use and that the QTL doesnt have is

erase(...)

Instead the QTL version is called

remove(...)


is there any reason behind that?

[d_stranz]

Different programmers.

It really isn't necessary to convert perfectly good code written using the STL to use QTL equivalents. When I ported code from MFC over to Qt, I left all of the STL-based code as is, and it works just fine. That way, I avoided problems like you are experiencing, where the two libraries have different naming or use conventions.

[tuli]

Some qt apis can only works with QTL containers, most notably serialization via QDataStream().

the QTL programmers have gone through a lot of effort to provide API-compatibility with the STL (and the STL is using wired naming conventions at times...), but they missed this very obvious one. Wired.

[Lykurg]

But instead altering your whole code base you could write some wrappers e.g. with QVector::fromStdVector().

[Santosh Reddy]

I am currently porting c++ code from STL to QTL (std::vector to QVector).
As other already suggested, this is not required. STL based code will work 100% along with Qt framework based code.

[d_stranz]

As other already suggested, this is not required. STL based code will work 100% along with Qt framework based code.

I guess the point we are all trying to make is that by porting solid, debugged code from STL to QTL just for the sake of "Qt purity" is likely to introduce new bugs. It is an example of the old saying: "If it isn't broken, don't fix it".

If the old code is buggy or inefficient, then porting might make sense because it gives you the opportunity to find and fix the bugs or make it work better. But just going through with global search and replace to change std::vector< double > into QVector< double > doesn't improve anything and is likely to make things worse when QTL doesn't act the same way as STL and you don't know why.

In my case, I have libraries that must be usable in both Qt and non-Qt applications. Sticking with STL in my core algorithms guarantees me not only cross-platform portability, but also independence from Qt where I need it.

[tuli]

i am not doing this to every stl container in my code; only very specific ones because only QTL containers can easily be serialized via QDataStream().


, most notably serialization via QDataStream().

I am not in for "Qt-purity", excuse my poor phrasing. :)

[d_stranz]

, most notably serialization via QDataStream().

The operator<<( QDataStream &, const QVector<T> & ) and operator>>( QDataStream &, QVector<T> & ) streaming operators are not members of the QVector<T> template class, they are external non-member template functions. You could quite easily implement these same operators that would act on the std::vector<T> class and achieve all the benefits of QDataStream without requiring any conversion of your existing STL code:



template < typename T >
QDataStream & operator<<( QDataStream & s, const std::vector<T> & v )
{
s << v.size();
std::vector<T>::const_iterator it = v.begin();
std::vector<T>::const_iterator eit = v.end();
while ( it != eit )
s << *it++;
return s;
}

template < typename T >
QDataStream & operator>>( QDataStream & s, std::vector<T> & v )
{
size_t nItems;
s >> nItems;
v.resize( nItems );

std::vector<T>::iterator it = v.begin();
std::vector<T>::iterator eit = v.end();
while ( it != eit )
s >> *it++;
return s;
}


And the like for any STL container class. Of course, operator>>() and operator<<() must be defined for whatever T is in the container, along with a default constructor for T.