[Development] Reverting the QRegExp change?
dangelog at gmail.com
Wed May 2 11:21:36 CEST 2012
On 2 May 2012 09:48, Thiago Macieira <thiago.macieira at intel.com> wrote:
> Given the negative reaction here and on Gerrit, I'm wondering if we should
> revert it.
> In fact, for the simple fact that the SIC change wasn't discussed here before
> it went in (my bad, sorry for that), it deserves to be reverted.
> What do you think?
That two kind of assestments for end-user code must be done:
1) checking the actual breakages (f.i. compiling Creator or KDE are
2) checking if it's worth it to spend N days of work (Brad said he
spent a full day to fix Creator) going around and replacing every
rx.indexIn(...) with sth like QRegExp copy(rx); copy.indexIn()
> Another option is what Olivier has proposed:
Adding the const overloads to avoid breaking the source is a good
idea. I'm not too happy with *that* implementation... the point of
your change was
1) that a const method is not supposed to modify the object in any
2) to avoid to break the (totally undocumented) assumption that
calling const methods on a reentrant class is actually thread safe;
well: now those const overloads are not doing any of 1+2, bringing us
to the situation before your change. So why dropping the const in the
first place?! :)
In a related patch I suggested something like
int QRegExp::foo() const
QRegExp copy = *this;
which although being source compatible, is behaviour incompatible
(QRegExp users do expect const methods to change the object -- it's
So it's a matter of deciding what's the least worst option.
(For an extreme bikeshedding round, is anyone really relying on a
const QRegExp object to modify itself? I tend to believe that if one
is really interested in the captured texts, etc. then it's very likely
that she's already using a non-const object!)
More information about the Development