On Tue, Dec 19, 2023 at 12:07 PM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> Replying to Thiago and Arthur in series below . . .
>
>
> On Mon, Dec 18, 2023 at 9:59 PM Thiago Macieira wrote:
> >
> > We might as well not have private and protected in the language then. Why
> > don't you write a paper to suggest we deprecate them?
>
>
> 'private' and 'protected' are useful, in particular when it comes to SFINAE.
>
> But even though I have a lock on the front door of my house, I have a
> key for it hidden nearby. It's not bad practise to provide a way to
> circumvent a system in unusual circumstances.

It is if you have a sign pointing everyone to the key.

> I mean people are
> already editing proprietary header files to change members from
> private to public, or even worse: "#define private public".

The thing you keep not understanding is that the fact that some people
do a thing does not mean that this thing should be allowed or
normalized by the standard. Bad practices exist and are sometimes
semi-common.

That doesn't stop them from being bad practices. If you want them to
be standardized, you need to explain how they aren't bad practices.

> If they
> can have safe spaces for injections in big cities to minimise harm
> then we can also have a way of forcing friendship in C++. Better to do
> it safely and without violating SFINAE then going all out with
> "#define private public".
>
>
> On Mon, Dec 18, 2023 at 11:25 PM Arthur O'Dwyer wrote:
> >
> > But you cannot have the mental model that "an object of type T" ever exists in
> > misaligned space, or that you're "relocating" from an object of type T into
> > misaligned space. That's simply physically impossible.
>
>
> The whole 'object model' is already a bit metaphysical and airy-fairy
> and make-believe. I have to really force myself to take functions like
> "start_lifetime_as" seriously (maybe it's because I program
> microcontrollers all day and am a bit closer to the copper).

To you, it may be make-believe. But the C++ standard takes it
seriously. And since we're here to talk about changing that standard,
you must take it seriously too.

> Just as an aside. . . if an object contains a pointer to itself . . .
> then relocating it from unaligned space into aligned space could get a
> little more complicated if the pointer inside it is anything other
> than 'void*' or 'char*', because a pointer such as 'long double*'
> might have less bits of precision for the memory address than a
> 'char*'.

If an object contains a pointer into itself, relocating it *period* is
a problem. It doesn't matter what type the pointer is of; you can't
just do a memcpy and expect to get reasonable results out the other
end, since the pointer will be pointing back into the old former
object that no longer exists.