'lightweight' QDir::isAbsolutePath replacement ?

[Ralf Habacker]

Thiago Macieira schrieb:
> On Monday 10 March 2008 20:20:42 Ralf Habacker wrote:
>   
>> Thiago Macieira schrieb:
>>     
>>> Ralf Habacker wrote:
>>>       
>>>> But - now the main question - is anyone from the trolltech devs here who
>>>> can ensure that such a patch would be accepted ?
>>>>         
>>> Yes.
>>>
>>> Everybody laughed at lunch when I explained the number of classes it had
>>> to go through just to do some string comparisons (on Unix, to look at the
>>> first character).
>>>
>>> Depending on the size of the patch, I'll push it to Qt 4.4.
>>>       
>> The patch is appended. It adds
>> static bool QFileInfo::isAbsolute(const QString &path);
>> static bool QFileInfo::isRelative(const QString &path);
>>
>> and fixes
>> static bool QDir::isAbsolutePath(const QString &path);
>> static bool QDir::isRelativePath(const QString &path);
>>
>> all the above mentioned methods are based on
>> static bool QFSFileEngine:isAbsolutePath(const QString &path);
>> static bool QFSFileEngine::isRelative(const QString &path);
>>
>> which makes the internal string compare functions accesable
>>     
>
> I have looked at the patch and it looks sane. At least, it didn't break any 
> existing tests we have.
>
> HOWEVER, it introduces a possibly bad behaviour change: if you have:
> 	QFile("foo:filename.html");
> using a dedicated file engine, only that file engine is capable of knowing 
> whether the given filename is an absolute path or not. Note how there are no 
> slashes in the given filename (it's *not* a URL), but it still could be 
> considered an absolute path.
>
> So I don't think we can escape the creation of a file engine. The best I can 
> do is go through the attempts to create, but in case of fallback to the 
> default file engine, not create it.
>
> I'll work on this a little more.
>   
In the early state of this patch i tried to precreate a QFileInfo 
instance to avoid creating a new instance every time but this helps only 
a little. It looks that the call tree to the string compare function is 
the problem.

BTW: to give you a feeling about the possible performance increase. The 
implementation in the patch is 16 time faster than the old one.

Ralf