2015-10-17 8:58 GMT+04:00 Thiago Macieira <thiago.macie...@intel.com>:
> On Saturday 17 October 2015 07:14:58 Konstantin Ritt wrote:
> > 2015-10-17 6:23 GMT+04:00 Thiago Macieira <thiago.macie...@intel.com>:
> > > On Saturday 17 October 2015 03:34:51 Konstantin Ritt wrote:
> > > > - QString::fromRawData(u"hello world", 5) /* { d=nullptr, b=.., s=5
> } */
> > >
> > > -
> > >
> > > > explicitly means "no owning, deep-copy when necessary"
> > >
> > > And when is it necessary?
> >
> > In a given example, left() derives the original data, even when it isn't
> > shared, whilst leftRef() produces a non-shared QString, just like
> proposed
> > QStringView.
>
> You missed the point.
>
> The whole problem of QString::fromRawData is that the method you called may
> store the QString and thus keep referencing the string you had, even past
> the
> point where your string changed.
>
> In fact, that happens with QStringLiteral too. If you use QStringLiteral
> in a
> plugin and the plugin gets unloaded, the application may crash.
>
Indeed, it is the same issue. QStringView doesn't solve it either.
So the best thing we can do, IMO, is to give the user a tool and describe
how to use it properly to get some extra performance, on his own risk.
> The whole point here was "deep-copy when necessary": when is it necessary?
> If
> we can't solve the two problems above, we are going to make the problem
> worse.
We could probably introduce a QString::ensureSharable() for the advanced
user's goals
and maybe call it in the copy constructor and the assignment operator to
avoid storing a data we do not own. The latter would potentially kill all
the extra performance we got in a first place, though.
In any way, QString::fromRawData() currently has the issue you've described
above, so I have some doubts we'll make the problem even worse.
Regards,
Konstantin
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
