Em sex 21 fev 2014, às 12:49:08, Thiago Macieira escreveu:
> 1) keep a non-null d for an empty-but-not null object (size == 0)
> a) d points to a read-write section of memory where we can ref up and down
> drawback: slowness due to atomic operations in multiple cores
>
> b) d points to another
Em sex 21 fev 2014, às 20:11:20, Marc Mutz escreveu:
> On Thursday 20 February 2014 08:32:54 Thiago Macieira wrote:
> > Please raise your hand if you knew we had that feature.
>
> I'm sure you know that COW implementations that hand out references to
> shared state need the sharable flag[1]. So ar
Em sex 21 fev 2014, às 16:49:39, Oswald Buddenhagen escreveu:
> ah, you are thinking qt 6 here.
Yes. I'd rather do the deprecation as soon as possible so we can have a
smoother transition when we come to it.
> > Obviously, if the d-pointer is null, neither the pointer to the data nor
> > the si
On Thursday 20 February 2014 08:32:54 Thiago Macieira wrote:
> Please raise your hand if you knew we had that feature.
I'm sure you know that COW implementations that hand out references to shared
state need the sharable flag[1]. So are we talking about removing the public
part of the API?
Than
On Thu, Feb 20, 2014 at 12:07:44PM -0800, Thiago Macieira wrote:
> Em qui 20 fev 2014, às 19:56:42, Oswald Buddenhagen escreveu:
> > what are you planning to do?
>
> This is the first step: remove setSharable so we have one fewer state to
> check
> during ref up & down. Keeping isSharedWith is n
Em qui 20 fev 2014, às 19:56:42, Oswald Buddenhagen escreveu:
> what are you planning to do?
This is the first step: remove setSharable so we have one fewer state to check
during ref up & down. Keeping isSharedWith is no problem, as it doesn't affect
the refcounting.
The second step will be to
On Thu, Feb 20, 2014 at 09:12:29AM -0800, Thiago Macieira wrote:
> The others are obscure indeed. As part of my efforts, I want to make QString
> /
> QByteArray / QVector keep a null d pointer for anything that doesn't require
> deallocation and reference counting -- that is, everything that is
>
> I agree on detach(): you can easily trigger a detach() by calling data().
> Well, as long as you ensure that your object is not const.
>
I wouldn't get rid of detach() just because data() can do the same thing. If
it is useful, I'd rather use the proper name for it.
The question is whether
Em qui 20 fev 2014, às 16:45:19, Tony Van Eerd escreveu:
> > -Original Message-
> > On Behalf Of Thiago Macieira
> > Subject: [Development] RFC: Deprecating setSharable / isSharable in our
> > containers and QString
> >
> > ... and removing them in Qt
> -Original Message-
> On Behalf Of Thiago Macieira
> Subject: [Development] RFC: Deprecating setSharable / isSharable in our
> containers and QString
>
> ... and removing them in Qt 6
>
> Please raise your hand if you knew we had that feature.
>
They aren&
On 20 Feb 2014, at 08:32, Thiago Macieira wrote:
> ... and removing them in Qt 6
>
> Please raise your hand if you knew we had that feature.
Never heard of this.
>
> Please raise your hand if you've ever used them in your own code.
So, never ever used it, and never had a need for such function
On 20/02/14 08:32, "Thiago Macieira" wrote:
>... and removing them in Qt 6
>
>Please raise your hand if you knew we had that feature.
>
>Please raise your hand if you've ever used them in your own code.
>
>I doubt anyone has raised their hands to the second question and there
>mustn't
>be more t
... and removing them in Qt 6
Please raise your hand if you knew we had that feature.
Please raise your hand if you've ever used them in your own code.
I doubt anyone has raised their hands to the second question and there mustn't
be more than 2 people who did for the first question. This is a
13 matches
Mail list logo
