On 22/10/15 10:56, "Paul Olav Tvete" <paul.tv...@theqtcompany.com> wrote:
>On Tuesday 20. October 2015 23.37.27 Thiago Macieira wrote: >> Em qua 21 out 2015, às 06:29:30, Knoll Lars escreveu: >> > As I remember it, the change from QSubString to QStringRef was a >>simple >> > API >> > naming decision, i.e. independent of the implementation details. >> >> Then it must be a coincidence that it changed internals more or less at >>the >> same time. > >Both were committed at the same time (in change >138d1ab051ed4934b303fa7a43a27dc4004e3ff9 for those who have access to the >old >Qt history). > >Date: Mon Jan 15 14:59:53 2007 +0100 >Commit message: "Removed QSubString again, and introduced a lower-level >class >QStringRef" > >QSubString had a QString::Data *d member, and the initial QStringRef had >a >const QString *m_string, just like today. > >I have only skimmed the thread, so I'm probably misunderstanding >something, >but I don't see how a QString pointer is that much safer than a Data >pointer, >or a QChar pointer. Unless you participate in the ref counting it’s only slightly safer. It’s safe against modifications of the string that do not shrink it’s length. > > >A safe class would use the implicit sharing by keeping a QString member, >but I >don't know how that would impact performance. Not a good idea IMO, as you’ll need to increase and decrease the refcount of often trivial operations. In addition, I think a QChar pointer + length is a better idea, as it also allows wrapping data that’s not contained in a QString. Cheers, Lars _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
