QString/QByteArray: detach immediately in operator[]

Unlike any other implicitly shared container, QString/QByteArray
have a "lazy detach" mechanism: their operator[] returns a
special object; assignment into that object will actually
detach.

In other words:

  QString a("Hello");
  QCharRef c = a[0];  // does not detach
  c = 'J';            // detach happens here

This allows this behavior:

  QString a("Hello");
  QCharRef c = a[0];
  QString b = a;
  c = 'J';               // detach happens here
  assert(a == "Jello");
  assert(b == "Hello");

Note that this happens only with operator[] -- the mutating
iterator APIs instead detach immediately, making the above code
have visible side effects in b (at the end, b == "Jello").

The reasons for this special behavior seems to have been lost in
the dawn of time: this is something present all the way back
since Qt 2, maybe even Qt 1. Holding on to a "reference" while
taking copies of a container is documented [1] to be a bad idea,
so we shouldn't double check that the users don't do it.

This patch:

1) adds an immediate detach in operator[], just like all other
containers;

2) adds a warning in debug builds in case QByteRef/QCharRef is going
to cause a detach;

3) marks operator[] as [[nodiscard]] to warn users not using
Clazy about the (unintended) detach now happening in their code.

This paves the way for removal of QCharRef/QByteRef, likely in
Qt 7.

[1] https://doc.qt.io/qt-5/containers.html#implicit-sharing-iterator-problem

[ChangeLog][QtCore][QString] QString::operator[] detaches
immediately. Previously, the detach was delayed until a
modification was made to the string through the returned
QCharRef.

[ChangeLog][QtCore][QByteArray] QByteArray::operator[] detaches
immediately. Previously, the detach was delayed until a
modification was made to the byte array through the returned
QByteRef.

Change-Id: I9f77ae36759d80dc3202426a798f5b1e5fb2c2c5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
 
 
 
 
 
 
 

0 files changed, 0 insertions, 0 deletions