Here is my opinion.

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.

获取Outlook for Android<https://aka.ms/AAb9ysg>

________________________________
发件人: Std-Proposals <std-proposals-bounces_at_[hidden]> 代表 Tiago Freire via Std-Proposals <std-proposals_at_[hidden]>
发送时间: 星期二, 七月 23, 2024 11:19:27 下午
收件人: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
抄送: Tiago Freire <tmiguelf_at_[hidden]>
主题: Re: [std-proposals] all bytes zero == null object

It still hasn't answered the question as to why?
This asks for special treatment of certain classes, as vector<bool> is anything to go by it was a terrible idea.
What you would be saving is 1byte, perhaps 8 as a realistic worst case (or whatever max alignment is).
As a consequence, it's going to be more complex to check if the object is constructed (which takes place at least twice, once by the user and another by the destructor), since now the invalid state can be multiple words it is more expensive to check.
The most important question here is why would you want to do this? Why?

________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden].org> on behalf of Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]>
Sent: Tuesday, July 23, 2024 10:56:46 AM
To: std-proposals_at_lists.isocpp.org <std-proposals_at_[hidden]>
Cc: Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>
Subject: Re: [std-proposals] all bytes zero == null object

On Mon, Jul 22, 2024 at 4:58 PM Ville Voutilainen wrote:
>
> Indeed. Furthermore, for example, you can have code that processes the
> optional, checks that it's engaged,
> and then hands the result of *opt to some other code for filling in
> the value, perhaps by simple assignment. If you don't know the
> difference between a disengaged optional and an optional holding a
> 'null' value, then you can no longer
> do that.
>
> And there's of course the rather canonical database field example,
> where there is a difference between a field
> not being set at all, and a field being set to a null string. Or null
> whatever, but nevertheless set to some value, possibly null.


This isn't what I meant. Let me give the example of a class that
tracks at any one time 2 - 4 unique semaphores:

    class Tracker {
        typedef std::counting_semaphore<3> Sem;
        std::atomic<Sem*> sems[4u];
    public:
        Tracker(Sem *const s0,Sem *const s1,Sem *const s2 =
nullptr,Sem *const s3 = nullptr)
        {
                if ( nullptr != s0 ) { assert( s0 != s1 ); assert( s0
!= s2 ); assert( s0 != s3 ); }
                if ( nullptr != s1 ) { assert( s1 != s0 ); assert( s1
!= s2 ); assert( s1 != s3 ); }
                if ( nullptr != s2 ) { assert( s2 != s1 ); assert( s2
!= s0 ); assert( s2 != s3 ); }
                sems[0] = s0;
                sems[1] = s1;
                sems[2] = s2;
                sems[3] = s3;
        }
        // other methods go here for manipulating the semaphores
    };

Given that an object of the type 'Tracker' must always track at least
2 semaphores, we know that at least 2 of its 4 pointers won't be a
nullptr. Furthermore, even if we were working with a machine for which
all bits zero is a valid memory addresss (and therefore nullptr must
be something other than all bits zero), the second pointer must be
unequal to the first pointer, so there must be one bit set high
somewhere.

An object of type 'Tracker' that has all bytes zero simply cannot
exist -- it is not a valid object. Never will there be such an object.
Perhaps my terminology of a 'null object' wasn't a good choice.

Therefore, an implementation of "std::optional<Tracker>", in
implementing the 'reset' method, can call "~Tracker()" and then simply
do a 'memset all zero' on the storage space. After that, the
'has_value' method can just check if all bytes are zero.
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals