Date: Mon, 22 May 2023 13:29:33 +0300
>
> The element type is pair<K const, V> and the data member layout of pair is
> fully prescribed.
I think we were talking about std::set here, not about std::map.
Anyway, are you sure about the `pair<const T1, T2>` case? const_cast says:
> const_cast makes it possible to form a reference or pointer to non-const
> type that is actually referring to a const object
> <https://en.cppreference.com/w/cpp/language/cv>
>
Const object says:
> *const object* - an object whose type is const-qualified, or a
> non-mutable subobject of a const object.
>
To me it doesn't look like `pair<const T1, T2>` satisfies any of the above.
On Mon, May 22, 2023 at 1:07 PM Edward Catmur <ecatmur_at_[hidden]>
wrote:
>
>
> On Mon, May 22, 2023, 04:44 Oleksandr Koval via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> I don't think it's UB since the underlying memory is not read-only.
>>
>
> The underlying memory very much is read only. The element type is pair<K
> const, V> and the data member layout of pair is fully prescribed.
>
> Arthur's solution can be improved using hints but I think that would still
>> require checking node(s) around the hint to verify that position is correct.
>> Btw, boost::container::set works in the way you need.
>>
>> On Mon, May 22, 2023 at 9:32 AM Thiago Macieira via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> On Sunday, 21 May 2023 14:09:30 PDT Frederick Virchanza Gotham via Std-
>>> Proposals wrote:
>>> > I wrote the following code today; I have a struct for storing an IP
>>> > address as well as two booleans (one for a FTP server and one for a
>>> > Samba file server):
>>> >
>>> > struct IPFileShare {
>>> > std::uint32_t ip;
>>>
>>> <rant>IP addresses aren't 32-bit and haven't been since the late 1990s.
>>> Is
>>> your code stuck in the 80s?</rant>
>>>
>>> Let's not ever write or even suggest code that fails to work with IPv6.
>>>
>>> > I think strictly speaking, the Standard says that this is undefined
>>> > behaviour. How about we change the Standard to say that this
>>> > const_cast is allowed so long as it has no effect on the sorting?
>>>
>>> In addition to what Arthur said, std::set is not just about sorting,
>>> it's
>>> about identity. The fact that your type seems to carry extra information
>>> that
>>> is not part of the identity does not mean it's the case for all other
>>> types.
>>>
>>> Let's not break the requirements without compelling reason. I didn't see
>>> a
>>> compelling reason why it has to be this way. What other alternatives
>>> have you
>>> explored and what were their drawbacks?
>>>
>>> --
>>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>> Software Architect - Intel DCAI Cloud Engineering
>>>
>>>
>>>
>>> --
>>> Std-Proposals mailing list
>>> Std-Proposals_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>
>>
>>
>> --
>> Regards,
>> Oleksandr Koval.
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>
> The element type is pair<K const, V> and the data member layout of pair is
> fully prescribed.
I think we were talking about std::set here, not about std::map.
Anyway, are you sure about the `pair<const T1, T2>` case? const_cast says:
> const_cast makes it possible to form a reference or pointer to non-const
> type that is actually referring to a const object
> <https://en.cppreference.com/w/cpp/language/cv>
>
Const object says:
> *const object* - an object whose type is const-qualified, or a
> non-mutable subobject of a const object.
>
To me it doesn't look like `pair<const T1, T2>` satisfies any of the above.
On Mon, May 22, 2023 at 1:07 PM Edward Catmur <ecatmur_at_[hidden]>
wrote:
>
>
> On Mon, May 22, 2023, 04:44 Oleksandr Koval via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> I don't think it's UB since the underlying memory is not read-only.
>>
>
> The underlying memory very much is read only. The element type is pair<K
> const, V> and the data member layout of pair is fully prescribed.
>
> Arthur's solution can be improved using hints but I think that would still
>> require checking node(s) around the hint to verify that position is correct.
>> Btw, boost::container::set works in the way you need.
>>
>> On Mon, May 22, 2023 at 9:32 AM Thiago Macieira via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> On Sunday, 21 May 2023 14:09:30 PDT Frederick Virchanza Gotham via Std-
>>> Proposals wrote:
>>> > I wrote the following code today; I have a struct for storing an IP
>>> > address as well as two booleans (one for a FTP server and one for a
>>> > Samba file server):
>>> >
>>> > struct IPFileShare {
>>> > std::uint32_t ip;
>>>
>>> <rant>IP addresses aren't 32-bit and haven't been since the late 1990s.
>>> Is
>>> your code stuck in the 80s?</rant>
>>>
>>> Let's not ever write or even suggest code that fails to work with IPv6.
>>>
>>> > I think strictly speaking, the Standard says that this is undefined
>>> > behaviour. How about we change the Standard to say that this
>>> > const_cast is allowed so long as it has no effect on the sorting?
>>>
>>> In addition to what Arthur said, std::set is not just about sorting,
>>> it's
>>> about identity. The fact that your type seems to carry extra information
>>> that
>>> is not part of the identity does not mean it's the case for all other
>>> types.
>>>
>>> Let's not break the requirements without compelling reason. I didn't see
>>> a
>>> compelling reason why it has to be this way. What other alternatives
>>> have you
>>> explored and what were their drawbacks?
>>>
>>> --
>>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>> Software Architect - Intel DCAI Cloud Engineering
>>>
>>>
>>>
>>> --
>>> Std-Proposals mailing list
>>> Std-Proposals_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>
>>
>>
>> --
>> Regards,
>> Oleksandr Koval.
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>
-- Regards, Oleksandr Koval.
Received on 2023-05-22 10:29:46