implicit QChar constructors
Christopher Eineke
kde-optimize@mail.kde.org
Thu, 23 Jan 2003 02:38:23 -0500
Oswald Buddenhagen wrote:
> too bad that qt's join() implementation
> plainly sucks - it's a simple loop with incremental concat, instead of
> a two-pass construct like the above function.
/me takes a look at the source for join...
-> O_O;;;
Holy christ, don't they know their own code? Why not calling setLength
before the loop?
//Original Qt code
QString QStringList::join( const QString &sep ) const
{
QString res;
bool alredy = FALSE;
for ( QStringList::ConstIterator it = begin(); it != end(); ++it ) {
if ( alredy )
res += sep;
alredy = TRUE;
res += *it;
}
return res;
}
//End original Qt code
//sledge's modified code
QString QstringList::join(const QString &seperator) const
{
QString result;
QStringList::ConstIterator it;
uint total_length;
bool already;
//Sum up string lengths
for (it = begin(); it != end(); ++it ) {
total_length += it->length();
}
//Create QString, preallocate memory (total_length)
QString str;
QString.setLength(total_length);
//Concatenating
for (it = begin(); it != end(); ++it ) {
if (already)
res += sep;
already = TRUE;
res += *it;
}
}
//End sledge's modified code
Two questions come up here...
1. Documentation error? (alredy/already)
2. Is iterating two times over the strings to get the total
length, allocate memory and then concatenating faster than iterating
one time and do "stupid" concatenating?
3. Is there a final seperator needed? One could argue about that...
--
Christopher Eineke, Exeter, Canada