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

List:       ktexteditor-devel
Subject:    To QString or to QStringList?
From:       Hamish Rodda <rodda () kde ! org>
Date:       2005-10-14 15:07:14
Message-ID: 200510150107.16240.rodda () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Hi,

I'm working on the ktexteditor 4.x interfaces at the moment, adding editing 
functions to the smart cursors and ranges.  I've got a dilemma currently that 
Christoph and I discussed briefly earlier - should the editing functions work 
with QString and parse for '\n', as currently, or should they take and 
receive QStringLists, or both?

(as an aside, I found that the function doing the splitting on '\n' was broken 
in katepart 3.x head, when i started adding regression testing... so i doubt 
it was actually used)

I'm leaning towards just QStringLists currently.  They match well with the 
underlying data structure - for larger text retrieval and edits (which is 
where this would count), most string copying can be avoided, whereas with 
straight QStrings, the append function does lots of realloc and memcpy.

I also feel that they wouldn't be too bad for usage in 3rd party code, but 
this is where my experience is a bit lacking.

Certainly, we could retain the plain QString versions for compatibility, if 
desired.  If we didn't want the compatibility layer, where existing code 
wants to pass the old QString, they could use QString::split().

I'm told that many text editors work with large buffers which include the 
newline characters inline, but that's not the way kate works and i doubt we'd 
be changing it.  Perhaps if another editor was to implement the ktexteditor 
interface, it would be more efficient for them to go with the plain QString 
version...

So, opinions?

Cheers,
Hamish.

[Attachment #5 (application/pgp-signature)]

_______________________________________________
Ktexteditor-devel mailing list
Ktexteditor-devel@kde.org
https://mail.kde.org/mailman/listinfo/ktexteditor-devel


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