[Development] QList

[Thiago Macieira]

Em domingo, 19 de março de 2017, às 11:44:44 PDT, Thiago Macieira escreveu:
> On sábado, 18 de março de 2017 14:33:32 PDT Marc Mutz wrote:
> > On Saturday 18 March 2017 19:30:35 Thiago Macieira wrote:
> > > class QStringView               - has all the const functions
> > > class QString : public QStringView      - adds the mutating functions
> > > class QtExclusive::QString : public QString
> > 
> > No inheritance. These things have no is-a relationship whatsoever.
> 
> Right, I came to the same conclusion in the shower after posting this and
> then forgot to post once I was out.

Ok, here's another shower idea. Instead of the above, we use a seldom used 
technique: private inheritance.

class QStringView
class QString : private QStringView
class QtExclusive::QString : private QString

Both QString and QtExclusive::QString would do a lot of:

	using QStringView::indexOf;
	using QStringView::contains;
	using QStringView::startsWith;
	using QStringView::endsWith;

plus:

	QString trimmed() &&;
	QString trimmed() const &;

etc.

In fact, most of the mutating functions in the exclusive class can be 
*exactly* the reference-counted version, as the reference count will be 1, so 
the detach() will do nothing.

The private inheritance solves this problem:

> My problem was the exclusive kind, because you could then do:
> 
> 	QtExclusive::QString es;
> 	QString &s = es;
> 	s = somethingElse();
> 	// es could now be sharing, which is a violation

The second line above would fail to compile.

At the same time, any changes to QStringView almost auomatically propagate to 
the other two classes. And almost all changes to QString go to 
QtExclusive::QString without even having to do anything.

Another thing I'd want is for QStringView to carry the pointer to the 
QArrayData like QString does. In the regular QStringView uses, it would be 
null. This has the drawback that QStringView would now be passed by implicit 
reference instead of by value in registers (though, as we discovered, Windows 
64-bit already does this). The reason I'd want this is for two use-cases:

1) when you create a QStringView from a QString (but not from 
QtExclusive::QString), it would carry the original string's QArrayData 
pointer. That's ok because if the pointer to the data is valid, the pointer to 
the allocation block is too. But when if you later did:

	m_string = sv;

the new QString would resume reference counting from the original QString, 
without actually creating a copy.

2) for SSO: on little-endian machines, we need the first byte to have bit 0 
set. The first byte is in the base class, so QStringView needs to start with 
that pointer.

For QStringView we could alternatively also the bit 0 in the data begin 
pointer, but that technique would not work for QByteArrayView.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center