Op 19-10-2015 om 17:54 schreef Thiago Macieira:
> First of all, QStringRef keeps a pointer to the original QString, so it isn't
> as fragile as QStringView. In fact, during the development of the XML stream
> classes, there was a QSubString class that did more or less what QStringView
> would do. I
On Tuesday 20 October 2015 09:44:23 Marc Mutz wrote:
> So if deep copies loose their ineffciency myth, what reason remains to not
> use QSV in all functions taking QString?
Complicating the API.
You cannot possibly prove that doing something O(n) is as efficient as doing
something O(1), therefo
On Tuesday 20 October 2015 01:08:31 Thiago Macieira wrote:
> So the summary of QStringView is:
> a) never used as return type
> b) used only as a parameter if the function processes the data and never
> stores it and will never, ever store it (lazy processing)
> c) for existing API, needs
Op 19-10-2015 om 22:31 schreef Bubke Marco:
> For example the highlighting can show that the parameter is an in or in/out
> parameter so you don't need to use pointers anymore for in/out parameters
> etc. But it is getting off topic.
https://bugreports.qt.io/browse/QTCREATORBUG-14468
André
On Monday 19 October 2015 20:31:53 Bubke Marco wrote:
> On October 19, 2015 21:38:51 Thiago Macieira
wrote:
> > Right. I'm simply saying that "if it can be used safely" is very, very
> > restricted.
> >
> > Suppose you have in v1:
> >
> > class Foo
> > {
> > QString m_data;
> > public:
> >
On Tuesday 20 October 2015 00:51:58 Olivier Goffart wrote:
> On Monday 19. October 2015 23:26:45 Marc Mutz wrote:
> > This particular mistake is easy to prevent statically, though:
> >
> >QStringView(QString &&) = delete;
>
> No.
>
> We want this to work:
>
> if (isValidIdentifier(myVarian
On Monday 19. October 2015 23:26:45 Marc Mutz wrote:
> This particular mistake is easy to prevent statically, though:
>
>QStringView(QString &&) = delete;
No.
We want this to work:
if (isValidIdentifier(myVariant.toString()))
with isValidIdentifier taking a QStringView and toString return
On October 19, 2015 21:38:51 Thiago Macieira wrote:
> On Monday 19 October 2015 18:38:52 Smith Martin wrote:
>> >Again, please try writing this method:
>> Doesn't that example just mean there are some classes that can't have a
>> QStringView API? A class should have a QStringView API if it can be
On Monday 19 October 2015 21:56:54 Smith Martin wrote:
> >This API here simply cannot exist because the returned value would be a
> >dangling reference.
>
> I don't understand. Implicit for using the QStringView data() function is
> knowing that once the QByteArray is set, it is never changed. Th
>This API here simply cannot exist because the returned value would be a
>dangling reference.
I don't understand. Implicit for using the QStringView data() function is
knowing that once the QByteArray is set, it is never changed. Then the data()
function is ok, isn't it?
martin
__
On Monday 19 October 2015 18:38:52 Smith Martin wrote:
> >Again, please try writing this method:
> Doesn't that example just mean there are some classes that can't have a
> QStringView API? A class should have a QStringView API if it can be used
> safely.
Right. I'm simply saying that "if it can b
>Again, please try writing this method:
Doesn't that example just mean there are some classes that can't have a
QStringView API? A class should have a QStringView API if it can be used safely.
martin
From: development-bounces+martin.smith=theqtcompany...
On Monday 19 October 2015 11:23:38 Marc Mutz wrote:
> On Sunday 18 October 2015 22:55:23 Thiago Macieira wrote:
> > On Sunday 18 October 2015 21:27:31 Giuseppe D'Angelo wrote:
> > > That the proposal is that every single function currently taking a
> > > QString should instead be changed to take a
On Monday 19 October 2015 07:14:55 Smith Martin wrote:
> >The point I'm trying to make
> >is that returning a non-owning copy means that something else must own the
> >data. That's what goes against the library code policy.
>
> The library code policy is an one that has always made sense in the
>
On 2015-10-16 19:52, Kurt Pattyn wrote:
> On 17 Oct 2015, at 01:18, Marc Mutz wrote:
>> I find it intolerable that todays software takes 1000x the memory,
>> 1000x the CPU capacity and doesn't get a given jobs done in less
>> wallclock time than software 20 years ago.
>
> These are 'numbers'. Is i
16.10.2015 18:18, Paeglis Gatis пишет:
>> Another question is what to do with the bundled libraries?
> The -qt-xcb switch is there to reduce run-time dependencies. There always
> will be somebody who wants
> to run the latest Qt version on some old linux distribution.
>
> Also I think it was decid
>That's like saying that functions musn't return a QStringRef. But see
>QXmlStreamReader, which uses that to (apparently) good effect.
That's a good point, but the other points you raise are just arguing by finding
fault with Qt. I think fully supporting QStringView has to be justified by
showin
On Sunday 18 October 2015 22:55:23 Thiago Macieira wrote:
> On Sunday 18 October 2015 21:27:31 Giuseppe D'Angelo wrote:
> > That the proposal is that every single function currently taking a
> > QString should instead be changed to take a QStringView instead, unless
> > a few exceptional cases (f
>The point I'm trying to make
>is that returning a non-owning copy means that something else must own the
>data. That's what goes against the library code policy.
The library code policy is an one that has always made sense in the
pre-string_view world. But if string_view is being added to C++,
19 matches
Mail list logo
