Replacing QRegExp with CMake RegularExpression

[Andreas Pakulat]

On 02.11.08 15:16:16, Aleix wrote:
> On Sun, Nov 2, 2008 at 2:59 AM, Andreas Pakulat <apaku at gmx.de> wrote:
> > The patch is attached for anyone to look at, whats a bit scary is the
> > conversion between QString and char* for the RegularExpression class. I'm
> > actually thinking about seeing wether converting to QChar helps with that
> > or wether using that class drains performance again.
> >
> .toAscii() works for me, why passing through QChar?

Well, mostly because I don't fully understand how the RegularExpression
class works and in which cases it holds on to any of the char* it was
given. Which is obviously a problem when you simply hand in
QString::toAscii()::data() because thats a temporary char*, its going to be
deleted as soon as the function call is done. Thats why the REGEX-REPLACE
part in cmakeprojectvisitor.cpp copies the char*. And the same thing the
other way around, you don't want to pass out a QString from
RegularExpression::match() which holds on to an internal char* of the RegEx
instance. 

I've seen one crash with the patch during closing kdevelop which might be
related to that kind of "memory juggling". Which is the reason why I'd try
to replace char* with QChar in the class.

Another reason is that basically we don't know (until we do a lot of
testing) how cmake behaves with files written in different encodings and
running cmake in again different encoding (like utf8-encoded CMakeLists.txt
running cmake in latin1 environment). So toAscii/toLocal8Bit are just
"guesses" and with QChar we could completely ignore these guesses and let
the kdelibs-encoding-detector find the right encoding of the file for
reading it in and then not worry anymore about it.

As I said, I'm just not sure about the overhead of QChar.

Andreas

-- 
You will be misunderstood by everyone.