On Tue, 19 Sept 2023 at 14:28, Patrice Roy <patricer_at_[hidden]> 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_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
>>
>