In the light of the C++ memory model being specified in terms of a virtual
machine, it seems an anomaly to me that the memory model is not also
specified in terms of a linear address space.

In this model, segmentation would be merely an implementation detail. This
would remove an enormous amount of unnecessary confusion from the language.

If people wanted to work in terms of small segments or paged program
memory, that is surely something that should be covered by compiler
extensions, no?



On Sun, 23 Jul 2023 at 08:27, Edward Catmur via Std-Discussion <
std-discussion_at_[hidden]> wrote:

>
>
> On Sun, 23 Jul 2023 at 06:37, Will Hawkins via Std-Discussion <
> std-discussion_at_[hidden]> wrote:
>
>> On Sat, Jul 22, 2023 at 2:47 PM Brian Bi via Std-Discussion
>> <std-discussion_at_[hidden]> wrote:
>> >
>> >
>> >
>> > On Sat, Jul 22, 2023 at 2:40 PM Lénárd Szolnoki via Std-Discussion <
>> std-discussion_at_[hidden]> wrote:
>> >>
>> >> Hi,
>> >>
>> >> Given these two arrays, each being a complete object:
>> >>
>> >> int a[2];
>> >> int b[2];
>> >>
>> >> The partial ordering of the addresses (defined by the operator <) of
>> >> the int objects within is:
>> >>
>> >> 1. &a[0] < &a[1]
>> >> 2. &b[0] < &b[1]
>> >>
>> >> A hostile strict total order that is consistent with this is
>> >> &a[0] < &b[0] < &a[1] < &b[1].
>> >>
>> >> Is there wording that prevents the implementation defined strict total
>> >> order to manifest like this?
>> >
>> >
>> > Not as far as I can tell.
>>
>> Does the last clause of https://eel.is/c++draft/intro.object#9 have
>> anything to say about this situation?
>>
>> ... otherwise, they have distinct addresses and occupy disjoint bytes
>> of storage."
>>
>
> "Disjoint" just means that incrementing a pointer to the first byte of one
> object through to the last byte of that object will not yield a pointer to
> a byte of the other object.
>
> The "hostile std::less<>" posited would have p R q and q R p+1 for some
> byte pointer p - that is, q is ordered between p and p+1 even though p and
> p+1 point to adjacent bytes of storage.
>
> Recall that std:less<> is just a strict total order that linearly extends
> each strict partial order on the pointers to objects and storage. There's
> nothing at present to say that it respects disjointedness of distinct
> objects.
>
> Sincerely,
>> Will
>>
>> >
>> >>
>> >>
>> >> One problem with this is that std::less is commonly used to check if a
>> >> given pointer points within a range. If such a manifestation is
>> >> possible then such usages are incorrect (or at least theoretically not
>> >> portable).
>> >
>> >
>> > I agree that this is something that should be banned. To be specific,
>> `&a[0] < &b[0] < &a[1] < &b[1]` is probably the sort of thing that is
>> supposed to be allowed, because the idea behind `<` not being a total order
>> is to support segmented architectures where e.g. it might only compare the
>> offset part of the address. But `std::less` always has to take into account
>> both the segment and offset, so I can't see any reason why it should be
>> allowed to give this "hostile" order.
>> >
>> >>
>> >>
>> >> Cheers,
>> >> Lénárd
>> >>
>> >> P.S. Someone pointed this out to me on the #include <C++> discord.
>> >> --
>> >> Std-Discussion mailing list
>> >> Std-Discussion_at_[hidden]
>> >> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>> >
>> >
>> >
>> > --
>> > Brian Bi
>> > --
>> > Std-Discussion mailing list
>> > Std-Discussion_at_[hidden]
>> > https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>> --
>> Std-Discussion mailing list
>> Std-Discussion_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>>
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>

-- 
Richard Hodges
hodges.r_at_[hidden]
office: +44 2032 898 513
home: +376 861 195
mobile: +376 380 212