Thanks Jonathan.

The suggestion was to strike the note. Maybe that's not the way to go, and
just clarifying the text to avoid confusion would be better. I think the
fact that it's QoI is known, and the hope is to make that request known to
vendors in hope for an adjustment where needed.

For this (and other) paths suggested by this paper, I will involve the
original contributors in the individual papers to come, and we'll try to
make sure they get to express their intent clearly. If some issues are
found to be non-issues after further examination and discussion, they will
be identified as such in further revisions of P2966.

Cheers!

Le mar. 19 sept. 2023 à 09:09, Jonathan Wakely via SG14 <
sg14_at_[hidden]> a écrit :

> Under “No RTTI” guarantees it says:
>
> Pursued. Many SG14 companies compile with
> RTTI turned off but might still want to use
> PMR allocators; however, some
> implementations use dynamic_cast in their
> PMR types. Offering PMR with a “no-RTTI”
> guarantee, or at least a compile-time
> checkable guarantee would be desirable.
> Consider eliminating note [mem.res.private-
> note-1]
>
>
> This is completely QoI. The standard doesn't require dynamic_cast there,
> and the note is talking about derived memory resources, possibly in the
> user's own code. It's just suggesting an optional optimization, which isn't
> needed at all, and can be made conditional on RTTI being enabled.
>
> If your implementation uses dynamic_cast unconditionally, complain to your
> vendor. They should do it conditionally, based on the __cpp_rtti feature
> test macro. That will work perfectly well with -fno-rtti or the equivalent.
>
> In any case, the only use of dynamic_cast I can find in any implementation
> of PMR is in GCC's experimental::resource_adaptor which already uses
> __cpp_rtti (and isn't in the standard yet, just a TS). Maybe the request
> should be considered for that type, as proposed for C++26 by P1083, but
> even there, I consider it completely QoI.
>
>
>
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>