pon., 30 sty 2023 o 12:48 Bo Persson via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> On 2023-01-30 at 12:20, Giuseppe D'Angelo via Std-Proposals wrote:
> > Hello,
> >
> > Il 30/01/23 07:04, Jason McKesson via Std-Proposals ha scritto:
> >> On Sun, Jan 29, 2023 at 8:36 PM Giuseppe D'Angelo via Std-Proposals
> >> <std-proposals_at_[hidden]> wrote:
> >>>
> >>> Hello,
> >>>
> >>> Il 29/01/23 22:11, Jason McKesson via Std-Proposals ha scritto:
> >>>> On Sun, Jan 29, 2023 at 3:41 PM Giuseppe D'Angelo via Std-Proposals
> >>>> <std-proposals_at_[hidden]> wrote:
> >>>>>
> >>>>> Hello,
> >>>>>
> >>>>> As per subject, I've been working on a proposal for a standardized way
> >>>>> to detect if a trivially default constructible type can be value
> >>>>> initialized by using `memset(0)` on some suitable storage.
> >>>>>
> >>>>> A draft is available here:
> >>>>>
> >>>>> https://isocpp.org/files/papers/D2782R0.html
> >
> > I've updated the draft incorporating many of the raised comments.
> >
> >
> >>>> However, I would suggest that it should be equally true/false for all
> >>>> pointers of the same category: object pointers, function pointers, and
> >>>> member pointers. Either all object pointers are
> >>>> trivially-zero-initializable or none of them are. Etc.
> >>>
> >>> Is there any reason for this? On Itanium, pointers to objects and to
> >>> functions can be zero-filled. Pointers to data members cannot. Why not
> >>> having the trait giving the factually correct answer? Surely one would
> >>> want a vector of `string_view`s to be zero-filled.
> >>
> >> I may not have explained what I meant very well.
> >>
> >> There are 3 categories of pointers: object pointers, function
> >> pointers, and member pointers. All pointers of a *particular* category
> >> have to give the same answer. So all object pointers are either
> >> trivially zero initializable or not. But all function pointers could
> >> have a *different* answer. Etc. So on Itanium, they could have
> >> function and object pointers be trivially zero initializable, but not
> >> member pointers.
> >>
> >> What it can't do is have `int*` be trivially zero initializable but
> >> `float*` not be.
> >
> > Ok, I got it now. But again, why imposing anything? We're entirely in
> > implementation-defined territory. "Who cares" if on some fancy
> > architecture `int *x=0;` is zero-filled and `float *y=0;` is not? The
> > compiler will tell you the truth for each different type.
> >
>
> I care if the code happens to compile on my machine, but nowhere else.
>
> Where is the portability, and how do you test the code?
>

Should this function make this trick?

```
template<typename T>
constexpr bool isZeroInit()
{
    T z = {};
    std::array<char, sizeof(z)> a = {};
    return std::bit_cast<decltype(a)>(z) == a;
}
```

It looks like it works for GCC and Clang,
it needs some guards to allow only simple types (no e.g. `std::string`),
but the core of this functionality is already available.

>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals