Thanks. The actual path to take will depend on the actual paper to come. Right now, what we have is a request for a «feature» in the list compiled by P2966, and until there is an actual paper written on that one I don't know what form the actual, formal request will take. I appreciate your guidance, and I'm sure the paper authors will too (it might save time in the end! :) )

Le mar. 19 sept. 2023 à 09:31, Jonathan Wakely <cxx@kayari.org> a écrit :


On Tue, 19 Sept 2023 at 14:28, Patrice Roy <patricer@gmail.com> wrote:
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.

Removing a note is not the right way to ask vendors to do things :-)

If there's a bug where dynamic_cast is used unconditionally when __cpp_rtti is not defined, that's just a bug, and should be reported to the vendor. It's not a WG21 issue.

Vendors that intend to support some kind of -fno-rtti mode should make non-standard changes to their std::lib implementation to work with that -fno-rtti mode. But that's entirely an issue for the vendors.

 

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@lists.isocpp.org> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg14