[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: RFC KURL rewite (1st STAGE)
From:       weis <weis () stud ! uni-frankfurt ! de>
Date:       1999-10-09 18:31:56
[Download RAW message or body]

Hi,

On Sat, 9 Oct 1999, Dawit Alemayehu wrote:

> On Sat, 9 Oct 1999, weis wrote :
> > Hi,
> 
> > while I consider it very useful to fix the shortcomings of
> > the current KURL, I would strongly suggest NOT to use
> > QRegExp! It is not very efficient!
> >
> > The current KURL and QUrl use state machines since they
> > are much more efficient than this QRegExp.
> >
> > In KDE and especially konqueror URLs are parsed in masses, so
> > parsing URLs is a time critical thing.
> 
> Thanks for the feedback.  My next step would have been to do some
> benchmark since I basically had the same concerns.  I did see the use of the
> state machines in KURL.
> 
> Perhaps I should have done that first before posting. A question though. 
> Should all use of QRegExp be avoided ?  I ask this because while converting the
> basic checks to a simple while loop is very trivial, the validation is not. As
> an example, look at the test for on the hostname which can only consist of
> alphanumeric & "-" values and they have to conform to a certain pattern. 
> 
> While we are on the performance topic, I saw a prevallant use of Qchar in the
> original code.  Was this done for performance purposes as well ? Is invoking 
> 
> QString mid ( uint index, uint len=0xffffffff ) const 
> 
> more expensive than creating new Qstring object out of
> 
> QString ( const QChar * unicode, uint length )  ?

That should be the same.

> 
> [OFF TOPIC :]  Would there be a possibility of having a Quri/Qurl class future
> versions of QT ?
>

Look at QUrl in the recent Qt CVS.

But they dont handle nested URLs like

tar:/path/file#file:/home/weis/x.tgz

Bye
Torben
 
> Regards,
> Dawit A.
> 
> 

[prev in list] [next in list] [prev in thread] [next in thread]