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

List:       pykde
Subject:    Re: [PyQt] Easy Segfault using (or misusing) QTextStream
From:       Phil Thompson <phil () riverbankcomputing ! com>
Date:       2013-08-15 21:45:20
Message-ID: b2d7ef53d4f57aa0521c86ea116e0677 () localhost
[Download RAW message or body]

On Thu, 15 Aug 2013 14:26:58 -0700, David Cortesi <davecortesi@gmail.com>
wrote:
> I had the problem that this sequence crashed Python:
> 
>  >>>> from PyQt4.QtCore import (Qt, QString, QTextStream)
>> >>>> ts = QTextStream(QString())
>> >>>> ts << u'x'
>> > Segmentation fault
>>
> 
> Phil properly reminded me that,
> 
> 
>> You need to keep a reference to the QString.
>>
> 
> And I thought, oh crap, another didn't-keep-a-ref bug. I'm a dope.
> 
> But later it occurs: this is a great nuisance, because what I want to do
is
> to call a function that returns a QTextStream ready to read. Maybe it is
> based on a file, or maybe it contains some boilerplate generated on the
fly
> -- The latter being an in-memory stream created as above.
> 
> So this function either has to have access to a global QString, or the
> caller has to pass a QString for it to use in case it needs one, or the
> function has to return a tuple (stream,
> QString-it-may-or-may-not-be-based-on) and the caller has to keep the
> string in scope.
> 
> It would be much cleaner if the QTextStream(QString) constructor could
take
> parental ownership of the QString it is passed. There is no question
about
> its being related to the new object and essential to it. Would this be a
Qt
> enhancement or a PyQt one?

PyQt - but a better solution would be to sub-class QTextStream and keep
the QString (actually a QByteArray would probably be better) as an instance
attribute.

Phil
_______________________________________________
PyQt mailing list    PyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[prev in list] [next in list] [prev in thread] [next in thread]