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