C++ Logo

std-proposals

Advanced search

Re: [std-proposals] all bytes zero == null object

From: Thiago Macieira <thiago_at_[hidden]>
Date: Tue, 23 Jul 2024 09:43:04 -0700
On Tuesday 23 July 2024 09:28:23 GMT-7 李 秋逸 via Std-Proposals wrote:
> If I can point out a sequence of bytes which is short enough and provide a
> magic value to distinguish whether there exist an object, there will not be
> a "more expensive" checking. For example, the capability of most vector
> can't be 0xffffffffffffffff. I can just read the bytes of the capability or
> set it.

I should also point out that this may be worse for code generation than the
extra alignof(T) content, especially when inlining.

In a simple example:

bool some_cond();
Foo some_value();
std::optional<Foo> conditional_value(bool b)
{
     return some_cond() ? some_value() : std::nullopt;
}
...

    if (auto opt = conditional_value(); opt)
        do_something(*opt);

When inlining conditional_value() in this next function, today the compiler
knows that the returned object will be engaged if and only if the conditional
it passed was true. We have a lot of examples showing the optional disappears
from the generated code and this becomes a simple control-flow expansion.

If you instead store a pattern inside of Foo, the compiler cannot conclude "if
and only if". It cannot conclude that some_value() will return a pattern that
is necessarily engaged, so it will need to emit the code to check that the
value returned from there is engaged.

Which it will always be if you've designed Foo correctly.


This is not a deal breaker. But it must be understood.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel DCAI Platform & System Engineering

Received on 2024-07-23 16:43:11