[Development] What's the status of a moved-from object?

[Edward Welbourne]

On Monday, 20 May 2019 06:56:56 PDT Lars Knoll wrote:
>>>> I actually think we should consider getting rid of shared_null and
>>>> instead have d == nullptr as the null/default constructed state of
>>>> the object. Yes, that means we need to check for d == nullptr in
>>>> member functions, but I don’t think the overhead is a problem, as d
>>>> will have to be loaded into a register in any case.

20.05.2019, 18:21, "Thiago Macieira" <thiago.macieira at intel.com>:
>>> It does introduce a compare-and-branch that wouldn't otherwise be
>>> there, but the cost is minimal compared to what most API would be
>>> doing, indeed.

In plenty of cases, it's just calling the same-named method on the d-ptr.

Result QThing::method(Type arg)
{
    return Q_LIKELY(d) ? d->method(arg) : Result();
}

On 20.05.19 17:27, Konstantin Tokarev wrote:
>> We should wrap d == nullptr in Q_UNLIKELY() to make branch predictor
>> assume non-null path by default.

Olivier Goffart (20 May 2019 18:34) wrote:
> I would not do that. Q_UNLIKELY does very little to the branch
> predictor, it only tell the compiler to put that part of the branch in
> a cold area (and also optimize for size instead of for speed)
> Might not be a good idea considering that default constructed object
> is actually quite likely.

Is it ?  I would hope that code relatively seldom calls methods on
default-constructed objects or moved-from objects.  Is the behaviour
even well-defined ?  Aside, of course, from assignment and destruction,
the two places where I would indeed omit Q_UNLIKELY().

	Eddy.