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.


Le mar. 19 sept. 2023 à 09:09, Jonathan Wakely via SG14 <> 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-

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