Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #80156 > unrolled thread
| Started by | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| First post | 2021-06-05 12:53 +0200 |
| Last post | 2021-06-07 14:52 +0000 |
| Articles | 20 on this page of 156 — 33 participants |
Back to article view | Back to comp.lang.c++
Is this really necessary Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-05 12:53 +0200
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-05 14:19 +0200
Re: Is this really necessary Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-05 14:27 +0200
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-05 14:33 +0200
Re: Is this really necessary Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-05 15:06 +0200
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-05 15:29 +0200
Re: Is this really necessary Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-05 17:38 +0200
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-05 17:51 +0200
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-06-05 11:56 -0400
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-06-05 19:08 -0400
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-06 11:24 +0200
Re: Is this really necessary Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-06-06 10:33 +0100
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-06-06 07:56 -0400
Re: Is this really necessary Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-06-06 15:00 +0100
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-06 16:20 -0700
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-06-07 00:44 -0700
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-07 12:13 -0700
Re: Is this really necessary Bo Persson <bo@bo-persson.se> - 2021-06-07 21:58 +0200
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-07 10:25 -0700
Re: Is this really necessary Bo Persson <bo@bo-persson.se> - 2021-08-07 21:21 +0200
Re: Is this really necessary Öö Tiib <ootiib@hot.ee> - 2021-06-05 06:34 -0700
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-06-05 20:03 -0400
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-07 12:59 -0700
Re: Is this really necessary MrSpud_85yGi2@1ahbfz.gov - 2021-08-08 09:18 +0000
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-08-08 09:23 -0400
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-08 15:04 +0000
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-08-08 13:14 -0400
Re: Is this really necessary MrSpud_1dgrmf@dx58865qyrdw30lqllb.info - 2021-08-09 08:21 +0000
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-09 08:53 +0000
Re: Is this really necessary "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-08-09 19:53 +0200
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-10 05:22 +0000
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-10 14:54 +0000
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-10 11:41 -0700
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-11 05:39 +0000
Re: Is this really necessary Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-08-08 20:01 +0100
Re: Is this really necessary MrSpud_ifhov@nldls6_1kg3nl2qnwv.biz - 2021-08-09 08:19 +0000
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-09 08:55 +0000
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-08-09 12:16 -0400
Re: Is this really necessary MrSpud_HG@_0b772d8ha3yjo0xb.edu - 2021-08-09 16:23 +0000
Re: Is this really necessary Vir Campestris <vir.campestris@invalid.invalid> - 2021-08-09 21:50 +0100
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-08-09 20:57 -0400
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-10 01:12 +0000
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-08-09 21:21 -0400
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-10 07:13 -0700
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-10 05:29 +0000
Re: Is this really necessary MrSpud_12tus_Atff@bya886olr5o8dhu9.ac.uk - 2021-08-10 07:28 +0000
Re: Is this really necessary Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2021-08-10 15:34 +0100
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-10 14:59 +0000
Re: Is this really necessary MrSpud_wPgnov999o@vv7a6.tv - 2021-08-10 15:54 +0000
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-10 11:29 -0700
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-11 08:45 +0000
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-11 07:05 -0700
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-11 14:18 +0000
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-10 14:57 +0000
Re: Is this really necessary MrSpud_pb9bpp7Ej@6urvt16b9fax.gov.uk - 2021-08-10 07:23 +0000
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-10 15:02 +0000
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-10 06:11 -0700
Re: Is this really necessary Bo Persson <bo@bo-persson.se> - 2021-08-10 16:13 +0200
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-11 12:40 -0700
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-12 08:20 +0000
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-12 03:50 -0700
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-12 14:58 +0000
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-12 08:29 -0700
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-12 15:39 +0000
Re: Is this really necessary Paavo Helde <myfirstname@osa.pri.ee> - 2021-08-12 20:07 +0300
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-13 07:16 +0000
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-13 09:26 +0000
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-08-13 10:30 -0400
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-13 14:58 +0000
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-14 08:07 +0000
Re: Is this really necessary "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-08-14 10:40 -0700
Re: Is this really necessary "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-08-14 10:38 -0700
Re: Is this really necessary "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-08-13 15:30 +0200
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-13 11:18 -0700
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-14 03:20 -0700
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-14 13:24 -0700
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-14 20:33 +0000
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-08-15 00:40 -0400
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-15 07:02 -0700
Re: Is this really necessary "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-08-15 21:19 +0200
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-08-15 15:42 -0400
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-21 12:38 -0700
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-14 08:13 +0000
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-14 02:58 -0700
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-13 14:32 +0000
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-14 02:28 -0700
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-14 03:00 -0700
Re: Is this really necessary Bart <bc@freeuk.com> - 2021-08-14 14:03 +0100
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-14 15:06 +0000
Re: Is this really necessary "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-08-12 12:06 -0700
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-13 09:19 +0000
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-13 14:35 +0000
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-13 14:58 +0000
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-10 15:03 +0000
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-11 12:54 -0700
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-11 20:20 +0000
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-12 03:42 -0700
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-11 05:45 +0000
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-11 05:26 -0700
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-11 14:06 +0000
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-08-11 14:01 +0000
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-08-09 23:20 -0400
Re: Is this really necessary MrSpud_m7k7yilq_8@u6w.biz - 2021-08-10 07:26 +0000
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-10 07:51 +0000
Re: Is this really necessary MrSpud_ggBp1lq0@lxz.tv - 2021-08-10 07:59 +0000
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-10 12:24 +0000
Re: Is this really necessary MrSpud_u7lm@bxuc3wy1g3cxiqu5j2x1_7iu.com - 2021-08-10 15:51 +0000
Re: Is this really necessary Juha Nieminen <nospam@thanks.invalid> - 2021-08-11 05:47 +0000
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-11 08:46 +0000
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-08-10 11:20 +0200
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-08-10 10:27 -0400
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-08-10 17:44 +0200
Re: Is this really necessary MrSpud_885p_dugji@l6zhsgj_v6t3dbj.tv - 2021-08-10 15:50 +0000
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-08-11 08:31 +0200
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-08-10 10:27 -0400
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-10 11:27 -0700
Re: Is this really necessary mickspud@downthefarm.com - 2021-08-11 08:44 +0000
Re: Is this really necessary Paavo Helde <myfirstname@osa.pri.ee> - 2021-08-11 16:05 +0300
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-10 06:41 -0700
Re: Is this really necessary Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-06 18:48 +0300
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-06-06 14:26 -0400
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-06 16:10 -0700
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-06-06 21:30 -0400
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-06 18:49 -0700
Re: Is this really necessary Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-06-06 18:51 -0700
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-06-06 22:57 -0400
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-06-07 09:43 -0700
Re: Is this really necessary Öö Tiib <ootiib@hot.ee> - 2021-06-07 09:51 -0700
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-07 10:22 -0700
Re: Is this really necessary "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-06-07 10:13 -0700
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-07 10:22 -0700
Re: Is this really necessary "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-08-07 12:40 -0700
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-08-07 12:54 -0700
Re: Is this really necessary Öö Tiib <ootiib@hot.ee> - 2021-06-06 23:17 -0700
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-06-07 09:19 -0700
Re: Is this really necessary Paavo Helde <myfirstname@osa.pri.ee> - 2021-06-07 21:58 +0300
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-06-10 11:29 -0700
Re: Is this really necessary Öö Tiib <ootiib@hot.ee> - 2021-06-05 05:38 -0700
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-05 15:41 +0200
Re: Is this really necessary Öö Tiib <ootiib@hot.ee> - 2021-06-05 08:18 -0700
Re: Is this really necessary Richard Damon <Richard@Damon-Family.org> - 2021-06-05 11:58 -0400
Re: Is this really necessary MrSpook_rs7x@4hhtozmpj299zx.tv - 2021-06-05 16:00 +0000
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-05 18:16 +0200
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-06 17:34 +0200
Re: Is this really necessary MrSpook_ie@q67rq6_2ly9ut44j.org - 2021-06-06 13:55 +0000
Re: Is this really necessary Bo Persson <bo@bo-persson.se> - 2021-06-05 19:50 +0200
Re: Is this really necessary MrSpook_zn7@4tzq7j92.gov - 2021-06-06 13:59 +0000
Re: Is this really necessary James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-06-05 17:42 -0400
Re: Is this really necessary David Brown <david.brown@hesbynett.no> - 2021-06-06 11:05 +0200
Re: Is this really necessary Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-06-07 00:27 -0700
Re: Is this really necessary Vir Campestris <vir.campestris@invalid.invalid> - 2021-06-06 21:27 +0100
Re: Is this really necessary "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-06-07 00:22 +0200
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-06-07 14:53 +0000
Re: Is this really necessary Bonita Montero <Bonita.Montero@gmail.com> - 2021-06-07 18:02 +0200
Re: Is this really necessary Vir Campestris <vir.campestris@invalid.invalid> - 2021-06-16 21:38 +0100
Re: Is this really necessary scott@slp53.sl.home (Scott Lurndal) - 2021-06-07 14:52 +0000
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-06-06 14:26 -0400 |
| Message-ID | <Er8vI.12770$7Y.3004@fx03.iad> |
| In reply to | #80187 |
On 6/6/21 11:48 AM, Paavo Helde wrote: > 05.06.2021 16:06 Bonita Montero kirjutas: >>> No. Subtraction of pointers is defined as the difference in their >>> indexes within a single array. >> >> That coudn't be true because you can cast any pointer-pair >> to char *, subtract them and use the difference for memcpy(). > > This holds only for linear memory model. While this is a dominant memory > model nowadays, the C++ language is old enough to take also other memory > models (like segmented ones) into account. In segmented memory models, > pointer arithmetic only works in a single segment, and accordingly the > arrays are limited to a single segment. There is no such limitation for > struct members. > > As an example, with Intel 386 you could have a 16-bit program working > simultaneously with at least 4 different 64 kB segments, which might > have been fully separate in the physical memory. Good luck with forming > a difference of pointers in a 16-bit size_t variable when the segments > are more than 64kB separate in the physical memory! > Actually, unless the pointers where specially declared, taking the difference ignored the segment part of the pointers and only subtracted the offsets, so if the pointers were to things in different segments, the difference was largely meaningless.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-06-06 16:10 -0700 |
| Message-ID | <87r1hevbc8.fsf@nosuchdomain.example.com> |
| In reply to | #80187 |
Paavo Helde <myfirstname@osa.pri.ee> writes:
> 05.06.2021 16:06 Bonita Montero kirjutas:
>>> No. Subtraction of pointers is defined as the difference in their
>>> indexes within a single array.
>>
>> That coudn't be true because you can cast any pointer-pair
>> to char *, subtract them and use the difference for memcpy().
>
> This holds only for linear memory model. While this is a dominant
> memory model nowadays, the C++ language is old enough to take also
> other memory models (like segmented ones) into account. In segmented
> memory models, pointer arithmetic only works in a single segment, and
> accordingly the arrays are limited to a single segment. There is no
> such limitation for struct members.
I believe there is. Without that limitation, the offsetof macro
wouldn't work.
> As an example, with Intel 386 you could have a 16-bit program working
> simultaneously with at least 4 different 64 kB segments, which might
> have been fully separate in the physical memory. Good luck with
> forming a difference of pointers in a 16-bit size_t variable when the
> segments are more than 64kB separate in the physical memory!
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-06-06 21:30 -0400 |
| Message-ID | <aFevI.570005$ST2.277494@fx47.iad> |
| In reply to | #80202 |
On 6/6/21 7:10 PM, Keith Thompson wrote: > Paavo Helde <myfirstname@osa.pri.ee> writes: >> 05.06.2021 16:06 Bonita Montero kirjutas: >>>> No. Subtraction of pointers is defined as the difference in their >>>> indexes within a single array. >>> >>> That coudn't be true because you can cast any pointer-pair >>> to char *, subtract them and use the difference for memcpy(). >> >> This holds only for linear memory model. While this is a dominant >> memory model nowadays, the C++ language is old enough to take also >> other memory models (like segmented ones) into account. In segmented >> memory models, pointer arithmetic only works in a single segment, and >> accordingly the arrays are limited to a single segment. There is no >> such limitation for struct members. > > I believe there is. Without that limitation, the offsetof macro > wouldn't work. > >> As an example, with Intel 386 you could have a 16-bit program working >> simultaneously with at least 4 different 64 kB segments, which might >> have been fully separate in the physical memory. Good luck with >> forming a difference of pointers in a 16-bit size_t variable when the >> segments are more than 64kB separate in the physical memory! > Actually, one reason offsetof is a Standard Macro so it can be made to use implementation dependent tricks to make it work here. The implementation has enough information to handle a bigger than a segment structure if it wanted to. It might only be able to make it work easily for 'real' mode where segments offset from the current segment can just be computed, or it might need special support from the OS to make multiple overlapping segments to build a net address space bigger than one segment long. If you reference an member of the structure whose offset is big enough that it won't fit in the first segment of the structure, the implementation just needs to make a segment offset from the start of the object that does hold that full member. I will say that I never heard of a compiler that did that for a structure, there were implementation that did that for specified arrays, but pointers to elements of that array had a non-standard type to keep track of the fact that segment updates might be needed for pointer arithmetic. These weree __huge__ arrays, with __huge__ pointers.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-06-06 18:49 -0700 |
| Message-ID | <87y2bmphoo.fsf@nosuchdomain.example.com> |
| In reply to | #80205 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 6/6/21 7:10 PM, Keith Thompson wrote:
>> Paavo Helde <myfirstname@osa.pri.ee> writes:
>>> 05.06.2021 16:06 Bonita Montero kirjutas:
>>>>> No. Subtraction of pointers is defined as the difference in their
>>>>> indexes within a single array.
>>>>
>>>> That coudn't be true because you can cast any pointer-pair
>>>> to char *, subtract them and use the difference for memcpy().
>>>
>>> This holds only for linear memory model. While this is a dominant
>>> memory model nowadays, the C++ language is old enough to take also
>>> other memory models (like segmented ones) into account. In segmented
>>> memory models, pointer arithmetic only works in a single segment, and
>>> accordingly the arrays are limited to a single segment. There is no
>>> such limitation for struct members.
>>
>> I believe there is. Without that limitation, the offsetof macro
>> wouldn't work.
>>
>>> As an example, with Intel 386 you could have a 16-bit program working
>>> simultaneously with at least 4 different 64 kB segments, which might
>>> have been fully separate in the physical memory. Good luck with
>>> forming a difference of pointers in a 16-bit size_t variable when the
>>> segments are more than 64kB separate in the physical memory!
>>
>
> Actually, one reason offsetof is a Standard Macro so it can be made to
> use implementation dependent tricks to make it work here.
>
> The implementation has enough information to handle a bigger than a
> segment structure if it wanted to. It might only be able to make it work
> easily for 'real' mode where segments offset from the current segment
> can just be computed, or it might need special support from the OS to
> make multiple overlapping segments to build a net address space bigger
> than one segment long.
>
> If you reference an member of the structure whose offset is big enough
> that it won't fit in the first segment of the structure, the
> implementation just needs to make a segment offset from the start of the
> object that does hold that full member.
>
> I will say that I never heard of a compiler that did that for a
> structure, there were implementation that did that for specified arrays,
> but pointers to elements of that array had a non-standard type to keep
> track of the fact that segment updates might be needed for pointer
> arithmetic. These weree __huge__ arrays, with __huge__ pointers.
Sure, and it can do the same thing for arrays.
Both array objects and struct objects has to *act like* they occupy a
contiguous range of memory addresses. If the implementation has to play
some tricks to make it act that way, that's fine. And if it restricts
object to a single segment, that's fine too (as long as the segment size
is big enough -- 65535 bytes for hosted implementations, C99 and later).
And if an implementation plays tricks for arrays but not for structures,
that's probably fine too. The standard doesn't mention segments.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-06-06 18:51 -0700 |
| Message-ID | <87tumaphlh.fsf@nosuchdomain.example.com> |
| In reply to | #80206 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
> Both array objects and struct objects has to *act like* they occupy a
> contiguous range of memory addresses. If the implementation has to play
> some tricks to make it act that way, that's fine. And if it restricts
> object to a single segment, that's fine too (as long as the segment size
> is big enough -- 65535 bytes for hosted implementations, C99 and later).
Or whatever the corresponding limits are for C++, of course. *sigh*
> And if an implementation plays tricks for arrays but not for structures,
> that's probably fine too. The standard doesn't mention segments.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-06-06 22:57 -0400 |
| Message-ID | <KWfvI.25213$v01.23286@fx07.iad> |
| In reply to | #80206 |
On 6/6/21 9:49 PM, Keith Thompson wrote: > Richard Damon <Richard@Damon-Family.org> writes: >> On 6/6/21 7:10 PM, Keith Thompson wrote: >>> Paavo Helde <myfirstname@osa.pri.ee> writes: >>>> 05.06.2021 16:06 Bonita Montero kirjutas: >>>>>> No. Subtraction of pointers is defined as the difference in their >>>>>> indexes within a single array. >>>>> >>>>> That coudn't be true because you can cast any pointer-pair >>>>> to char *, subtract them and use the difference for memcpy(). >>>> >>>> This holds only for linear memory model. While this is a dominant >>>> memory model nowadays, the C++ language is old enough to take also >>>> other memory models (like segmented ones) into account. In segmented >>>> memory models, pointer arithmetic only works in a single segment, and >>>> accordingly the arrays are limited to a single segment. There is no >>>> such limitation for struct members. >>> >>> I believe there is. Without that limitation, the offsetof macro >>> wouldn't work. >>> >>>> As an example, with Intel 386 you could have a 16-bit program working >>>> simultaneously with at least 4 different 64 kB segments, which might >>>> have been fully separate in the physical memory. Good luck with >>>> forming a difference of pointers in a 16-bit size_t variable when the >>>> segments are more than 64kB separate in the physical memory! >>> >> >> Actually, one reason offsetof is a Standard Macro so it can be made to >> use implementation dependent tricks to make it work here. >> >> The implementation has enough information to handle a bigger than a >> segment structure if it wanted to. It might only be able to make it work >> easily for 'real' mode where segments offset from the current segment >> can just be computed, or it might need special support from the OS to >> make multiple overlapping segments to build a net address space bigger >> than one segment long. >> >> If you reference an member of the structure whose offset is big enough >> that it won't fit in the first segment of the structure, the >> implementation just needs to make a segment offset from the start of the >> object that does hold that full member. >> >> I will say that I never heard of a compiler that did that for a >> structure, there were implementation that did that for specified arrays, >> but pointers to elements of that array had a non-standard type to keep >> track of the fact that segment updates might be needed for pointer >> arithmetic. These weree __huge__ arrays, with __huge__ pointers. > > Sure, and it can do the same thing for arrays. > > Both array objects and struct objects has to *act like* they occupy a > contiguous range of memory addresses. If the implementation has to play > some tricks to make it act that way, that's fine. And if it restricts > object to a single segment, that's fine too (as long as the segment size > is big enough -- 65535 bytes for hosted implementations, C99 and later). > > And if an implementation plays tricks for arrays but not for structures, > that's probably fine too. The standard doesn't mention segments. > The problem with doing it for arrays is that either you need to do it for ALL pointers, or you need to make big array use a special syntax. The key thing for structs is that the pointer to the big structure is already a special type, so is easy to recognize without cost to other code. In essence, you can treat a BigStruct* pointer special when you apply the member selection operation to it. Given a int* pointer into a big array, you don't know if it IS a big array, unless you pessimistically do for all, or make big arrays an extension that creates a special type of pointer that needs a non-standard type definition (like __huge__)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-06-07 09:43 -0700 |
| Message-ID | <86pmwxd3qq.fsf@linuxsc.com> |
| In reply to | #80208 |
Richard Damon <Richard@Damon-Family.org> writes: > On 6/6/21 9:49 PM, Keith Thompson wrote: > >> Richard Damon <Richard@Damon-Family.org> writes: >> >>> On 6/6/21 7:10 PM, Keith Thompson wrote: >>> >>>> Paavo Helde <myfirstname@osa.pri.ee> writes: >>>> >>>>> 05.06.2021 16:06 Bonita Montero kirjutas: >>>>> >>>>>>> No. Subtraction of pointers is defined as the difference in >>>>>>> their indexes within a single array. >>>>>> >>>>>> That coudn't be true because you can cast any pointer-pair to >>>>>> char *, subtract them and use the difference for memcpy(). >>>>> >>>>> This holds only for linear memory model. While this is a >>>>> dominant memory model nowadays, the C++ language is old enough >>>>> to take also other memory models (like segmented ones) into >>>>> account. In segmented memory models, pointer arithmetic only >>>>> works in a single segment, and accordingly the arrays are >>>>> limited to a single segment. There is no such limitation for >>>>> struct members. >>>> >>>> I believe there is. Without that limitation, the offsetof macro >>>> wouldn't work. >>>> >>>>> As an example, with Intel 386 you could have a 16-bit program >>>>> working simultaneously with at least 4 different 64 kB segments, >>>>> which might have been fully separate in the physical memory. >>>>> Good luck with forming a difference of pointers in a 16-bit >>>>> size_t variable when the segments are more than 64kB separate in >>>>> the physical memory! >>>> >>> >>> Actually, one reason offsetof is a Standard Macro so it can be >>> made to use implementation dependent tricks to make it work here. >>> >>> The implementation has enough information to handle a bigger than >>> a segment structure if it wanted to. It might only be able to >>> make it work easily for 'real' mode where segments offset from the >>> current segment can just be computed, or it might need special >>> support from the OS to make multiple overlapping segments to build >>> a net address space bigger than one segment long. >>> >>> If you reference an member of the structure whose offset is big >>> enough that it won't fit in the first segment of the structure, >>> the implementation just needs to make a segment offset from the >>> start of the object that does hold that full member. >>> >>> I will say that I never heard of a compiler that did that for a >>> structure, there were implementation that did that for specified >>> arrays, but pointers to elements of that array had a non-standard >>> type to keep track of the fact that segment updates might be >>> needed for pointer arithmetic. These weree __huge__ arrays, with >>> __huge__ pointers. >> >> Sure, and it can do the same thing for arrays. >> >> Both array objects and struct objects has to *act like* they occupy >> a contiguous range of memory addresses. If the implementation has >> to play some tricks to make it act that way, that's fine. And if >> it restricts object to a single segment, that's fine too (as long >> as the segment size is big enough -- 65535 bytes for hosted >> implementations, C99 and later). >> >> And if an implementation plays tricks for arrays but not for >> structures, that's probably fine too. The standard doesn't >> mention segments. > > The problem with doing it for arrays is that either you need to do > it for ALL pointers, or you need to make big array use a special > syntax. > > The key thing for structs is that the pointer to the big structure > is already a special type, so is easy to recognize without cost to > other code. > > In essence, you can treat a BigStruct* pointer special when you > apply the member selection operation to it. > > Given a int* pointer into a big array, you don't know if it IS a > big array, unless you pessimistically do for all, or make big > arrays an extension that creates a special type of pointer that > needs a non-standard type definition (like __huge__) In C a pointer to any object can be converted to unsigned char * which then can be used as though it were pointing into a character array whose extent covers the entire object. Do you have some reason to believe that property does not apply to C++?
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2021-06-07 09:51 -0700 |
| Message-ID | <be86c5b6-ca20-493e-9444-23427c85682dn@googlegroups.com> |
| In reply to | #80217 |
On Monday, 7 June 2021 at 19:44:12 UTC+3, Tim Rentsch wrote: > Richard Damon <Ric...@Damon-Family.org> writes: > > > On 6/6/21 9:49 PM, Keith Thompson wrote: > > > >> Richard Damon <Ric...@Damon-Family.org> writes: > >> > >>> On 6/6/21 7:10 PM, Keith Thompson wrote: > >>> > >>>> Paavo Helde <myfir...@osa.pri.ee> writes: > >>>> > >>>>> 05.06.2021 16:06 Bonita Montero kirjutas: > >>>>> > >>>>>>> No. Subtraction of pointers is defined as the difference in > >>>>>>> their indexes within a single array. > >>>>>> > >>>>>> That coudn't be true because you can cast any pointer-pair to > >>>>>> char *, subtract them and use the difference for memcpy(). > >>>>> > >>>>> This holds only for linear memory model. While this is a > >>>>> dominant memory model nowadays, the C++ language is old enough > >>>>> to take also other memory models (like segmented ones) into > >>>>> account. In segmented memory models, pointer arithmetic only > >>>>> works in a single segment, and accordingly the arrays are > >>>>> limited to a single segment. There is no such limitation for > >>>>> struct members. > >>>> > >>>> I believe there is. Without that limitation, the offsetof macro > >>>> wouldn't work. > >>>> > >>>>> As an example, with Intel 386 you could have a 16-bit program > >>>>> working simultaneously with at least 4 different 64 kB segments, > >>>>> which might have been fully separate in the physical memory. > >>>>> Good luck with forming a difference of pointers in a 16-bit > >>>>> size_t variable when the segments are more than 64kB separate in > >>>>> the physical memory! > >>>> > >>> > >>> Actually, one reason offsetof is a Standard Macro so it can be > >>> made to use implementation dependent tricks to make it work here. > >>> > >>> The implementation has enough information to handle a bigger than > >>> a segment structure if it wanted to. It might only be able to > >>> make it work easily for 'real' mode where segments offset from the > >>> current segment can just be computed, or it might need special > >>> support from the OS to make multiple overlapping segments to build > >>> a net address space bigger than one segment long. > >>> > >>> If you reference an member of the structure whose offset is big > >>> enough that it won't fit in the first segment of the structure, > >>> the implementation just needs to make a segment offset from the > >>> start of the object that does hold that full member. > >>> > >>> I will say that I never heard of a compiler that did that for a > >>> structure, there were implementation that did that for specified > >>> arrays, but pointers to elements of that array had a non-standard > >>> type to keep track of the fact that segment updates might be > >>> needed for pointer arithmetic. These weree __huge__ arrays, with > >>> __huge__ pointers. > >> > >> Sure, and it can do the same thing for arrays. > >> > >> Both array objects and struct objects has to *act like* they occupy > >> a contiguous range of memory addresses. If the implementation has > >> to play some tricks to make it act that way, that's fine. And if > >> it restricts object to a single segment, that's fine too (as long > >> as the segment size is big enough -- 65535 bytes for hosted > >> implementations, C99 and later). > >> > >> And if an implementation plays tricks for arrays but not for > >> structures, that's probably fine too. The standard doesn't > >> mention segments. > > > > The problem with doing it for arrays is that either you need to do > > it for ALL pointers, or you need to make big array use a special > > syntax. > > > > The key thing for structs is that the pointer to the big structure > > is already a special type, so is easy to recognize without cost to > > other code. > > > > In essence, you can treat a BigStruct* pointer special when you > > apply the member selection operation to it. > > > > Given a int* pointer into a big array, you don't know if it IS a > > big array, unless you pessimistically do for all, or make big > > arrays an extension that creates a special type of pointer that > > needs a non-standard type definition (like __huge__) > In C a pointer to any object can be converted to unsigned char * > which then can be used as though it were pointing into a > character array whose extent covers the entire object. > > Do you have some reason to believe that property does not apply > to C++? Yes in C++ it is so only about pointers to objects of trivially copyable or standard-layout types as only those are required to occupy contiguous bytes of storage.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-08-07 10:22 -0700 |
| Message-ID | <86y29d2mqw.fsf@linuxsc.com> |
| In reply to | #80218 |
Tiib <ootiib@hot.ee> writes: > On Monday, 7 June 2021 at 19:44:12 UTC+3, Tim Rentsch wrote: > >> Richard Damon <Ric...@Damon-Family.org> writes: >> >>> On 6/6/21 9:49 PM, Keith Thompson wrote: >>> >>>> Richard Damon <Ric...@Damon-Family.org> writes: >>>> >>>>> On 6/6/21 7:10 PM, Keith Thompson wrote: >>>>> >>>>>> Paavo Helde <myfir...@osa.pri.ee> writes: >>>>>> >>>>>>> 05.06.2021 16:06 Bonita Montero kirjutas: >>>>>>> >>>>>>>>> No. Subtraction of pointers is defined as the difference in >>>>>>>>> their indexes within a single array. >>>>>>>> >>>>>>>> That coudn't be true because you can cast any pointer-pair to >>>>>>>> char *, subtract them and use the difference for memcpy(). >>>>>>> >>>>>>> This holds only for linear memory model. While this is a >>>>>>> dominant memory model nowadays, the C++ language is old enough >>>>>>> to take also other memory models (like segmented ones) into >>>>>>> account. In segmented memory models, pointer arithmetic only >>>>>>> works in a single segment, and accordingly the arrays are >>>>>>> limited to a single segment. There is no such limitation for >>>>>>> struct members. >>>>>> >>>>>> I believe there is. Without that limitation, the offsetof macro >>>>>> wouldn't work. >>>>>> >>>>>>> As an example, with Intel 386 you could have a 16-bit program >>>>>>> working simultaneously with at least 4 different 64 kB segments, >>>>>>> which might have been fully separate in the physical memory. >>>>>>> Good luck with forming a difference of pointers in a 16-bit >>>>>>> size_t variable when the segments are more than 64kB separate in >>>>>>> the physical memory! >>>>>> >>>>> >>>>> Actually, one reason offsetof is a Standard Macro so it can be >>>>> made to use implementation dependent tricks to make it work here. >>>>> >>>>> The implementation has enough information to handle a bigger than >>>>> a segment structure if it wanted to. It might only be able to >>>>> make it work easily for 'real' mode where segments offset from the >>>>> current segment can just be computed, or it might need special >>>>> support from the OS to make multiple overlapping segments to build >>>>> a net address space bigger than one segment long. >>>>> >>>>> If you reference an member of the structure whose offset is big >>>>> enough that it won't fit in the first segment of the structure, >>>>> the implementation just needs to make a segment offset from the >>>>> start of the object that does hold that full member. >>>>> >>>>> I will say that I never heard of a compiler that did that for a >>>>> structure, there were implementation that did that for specified >>>>> arrays, but pointers to elements of that array had a non-standard >>>>> type to keep track of the fact that segment updates might be >>>>> needed for pointer arithmetic. These weree __huge__ arrays, with >>>>> __huge__ pointers. >>>> >>>> Sure, and it can do the same thing for arrays. >>>> >>>> Both array objects and struct objects has to *act like* they occupy >>>> a contiguous range of memory addresses. If the implementation has >>>> to play some tricks to make it act that way, that's fine. And if >>>> it restricts object to a single segment, that's fine too (as long >>>> as the segment size is big enough -- 65535 bytes for hosted >>>> implementations, C99 and later). >>>> >>>> And if an implementation plays tricks for arrays but not for >>>> structures, that's probably fine too. The standard doesn't >>>> mention segments. >>> >>> The problem with doing it for arrays is that either you need to do >>> it for ALL pointers, or you need to make big array use a special >>> syntax. >>> >>> The key thing for structs is that the pointer to the big structure >>> is already a special type, so is easy to recognize without cost to >>> other code. >>> >>> In essence, you can treat a BigStruct* pointer special when you >>> apply the member selection operation to it. >>> >>> Given a int* pointer into a big array, you don't know if it IS a >>> big array, unless you pessimistically do for all, or make big >>> arrays an extension that creates a special type of pointer that >>> needs a non-standard type definition (like __huge__) >> >> In C a pointer to any object can be converted to unsigned char * >> which then can be used as though it were pointing into a >> character array whose extent covers the entire object. >> >> Do you have some reason to believe that property does not apply >> to C++? > > Yes in C++ it is so only about pointers to objects of trivially copyable > or standard-layout types as only those are required to occupy > contiguous bytes of storage. Sorry, I thought it was obvious from context that my question was meant to ask only about contiguous objects.
[toc] | [prev] | [next] | [standalone]
| From | "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-06-07 10:13 -0700 |
| Message-ID | <77334d48-26bb-4ea4-b515-34a59e372397n@googlegroups.com> |
| In reply to | #80217 |
On Monday, June 7, 2021 at 12:44:12 PM UTC-4, Tim Rentsch wrote: ... > In C a pointer to any object can be converted to unsigned char * > which then can be used as though it were pointing into a > character array whose extent covers the entire object. > > Do you have some reason to believe that property does not apply > to C++? "An object of trivially copyable or standard-layout type (6.8) shall occupy contiguous bytes of storage." (6.7.2p8.4). Which implies that any type that is neither trivially copyable nor a standard-layout type need not occupy contiguous bytes of storage. C's requirement (6.2.6.1p2) has no such exceptions.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-08-07 10:22 -0700 |
| Message-ID | <8635rl41c7.fsf@linuxsc.com> |
| In reply to | #80219 |
"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes: > On Monday, June 7, 2021 at 12:44:12 PM UTC-4, Tim Rentsch wrote: > ... > >> In C a pointer to any object can be converted to unsigned char * >> which then can be used as though it were pointing into a >> character array whose extent covers the entire object. >> >> Do you have some reason to believe that property does not apply >> to C++? > > "An object of trivially copyable or standard-layout type (6.8) shall > occupy contiguous bytes of storage." (6.7.2p8.4). Which implies > that any type that is neither trivially copyable nor a > standard-layout type need not occupy contiguous bytes of storage. > C's requirement (6.2.6.1p2) has no such exceptions. Sorry, I thought it was obvious from context that my question was meant to ask only about contiguous objects.
[toc] | [prev] | [next] | [standalone]
| From | "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-08-07 12:40 -0700 |
| Message-ID | <075ac504-d31d-4685-9385-f582c21cc26bn@googlegroups.com> |
| In reply to | #80785 |
On Saturday, August 7, 2021 at 1:22:16 PM UTC-4, Tim Rentsch wrote: > "james...@alumni.caltech.edu" <james...@alumni.caltech.edu> writes: > > > On Monday, June 7, 2021 at 12:44:12 PM UTC-4, Tim Rentsch wrote: > > ... > > > >> In C a pointer to any object can be converted to unsigned char * > >> which then can be used as though it were pointing into a > >> character array whose extent covers the entire object. > >> > >> Do you have some reason to believe that property does not apply > >> to C++? > > > > "An object of trivially copyable or standard-layout type (6.8) shall > > occupy contiguous bytes of storage." (6.7.2p8.4). Which implies > > that any type that is neither trivially copyable nor a > > standard-layout type need not occupy contiguous bytes of storage. > > C's requirement (6.2.6.1p2) has no such exceptions. > Sorry, I thought it was obvious from context that my > question was meant to ask only about contiguous objects. No, it wasn't. The statement you made about C is about "any object", not "contiguous objects". It ceases to be true for C++ precisely because C++ allows objects to not be contiguous. The context of that statement was a comparison of arrays and structs, and while arrays are required to contiguous, structs are not. That discussion, in turn, evolved from an earlier discussion of offsetof(), which is only conditionally-supported in C++ for types that aren't standard-layout types.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-08-07 12:54 -0700 |
| Message-ID | <86mtpt2fq6.fsf@linuxsc.com> |
| In reply to | #80789 |
"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes: > On Saturday, August 7, 2021 at 1:22:16 PM UTC-4, Tim Rentsch wrote: > >> "james...@alumni.caltech.edu" <james...@alumni.caltech.edu> writes: >> >>> On Monday, June 7, 2021 at 12:44:12 PM UTC-4, Tim Rentsch wrote: >>> ... >>> >>>> In C a pointer to any object can be converted to unsigned char * >>>> which then can be used as though it were pointing into a >>>> character array whose extent covers the entire object. >>>> >>>> Do you have some reason to believe that property does not apply >>>> to C++? >>> >>> "An object of trivially copyable or standard-layout type (6.8) shall >>> occupy contiguous bytes of storage." (6.7.2p8.4). Which implies >>> that any type that is neither trivially copyable nor a >>> standard-layout type need not occupy contiguous bytes of storage. >>> C's requirement (6.2.6.1p2) has no such exceptions. >> >> Sorry, I thought it was obvious from context that my >> question was meant to ask only about contiguous objects. > > No, it wasn't. The statement you made about C is about "any object", > not "contiguous objects". It ceases to be true for C++ precisely > because C++ allows objects to not be contiguous. The context of > that statement was a comparison of arrays and structs, and while > arrays are required to contiguous, structs are not. That discussion, in > turn, evolved from an earlier discussion of offsetof(), which is only > conditionally-supported in C++ for types that aren't standard-layout > types. My statement was and is a true and correct statement.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2021-06-06 23:17 -0700 |
| Message-ID | <44b4cd88-c666-4b0e-a8e2-594c32448658n@googlegroups.com> |
| In reply to | #80202 |
On Monday, 7 June 2021 at 02:10:30 UTC+3, Keith Thompson wrote: > Paavo Helde <myfir...@osa.pri.ee> writes: > > > This holds only for linear memory model. While this is a dominant > > memory model nowadays, the C++ language is old enough to take also > > other memory models (like segmented ones) into account. In segmented > > memory models, pointer arithmetic only works in a single segment, and > > accordingly the arrays are limited to a single segment. There is no > > such limitation for struct members. > > I believe there is. Without that limitation, the offsetof macro > wouldn't work. In C++ offsetof is required only to work on standard layout types (UB otherwise). So (either there is some other constraint we haven't thought about or) only standard layout classes and arrays have to be limited to work in single segment (when memory is segmented).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-06-07 09:19 -0700 |
| Message-ID | <86tum9d4vs.fsf@linuxsc.com> |
| In reply to | #80187 |
Paavo Helde <myfirstname@osa.pri.ee> writes: > 05.06.2021 16:06 Bonita Montero kirjutas: > >>> No. Subtraction of pointers is defined as the difference in their >>> indexes within a single array. >> >> That coudn't be true because you can cast any pointer-pair >> to char *, subtract them and use the difference for memcpy(). > > This holds only for linear memory model. While this is a dominant > memory model nowadays, the C++ language is old enough to take also > other memory models (like segmented ones) into account. In segmented > memory models, pointer arithmetic only works in a single segment, and > accordingly the arrays are limited to a single segment. There is no > such limitation for struct members. In C there is, because any object can be treated as an array of character type, and that includes structs. In C++ the rules are so complicated that no one knows whether that reasoning applies, so the safest course of action is not to use C++ on machines that use segmentation.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-06-07 21:58 +0300 |
| Message-ID | <s9lq8t$4a3$1@dont-email.me> |
| In reply to | #80216 |
07.06.2021 19:19 Tim Rentsch kirjutas: > Paavo Helde <myfirstname@osa.pri.ee> writes: > >> 05.06.2021 16:06 Bonita Montero kirjutas: >> >>>> No. Subtraction of pointers is defined as the difference in their >>>> indexes within a single array. >>> >>> That coudn't be true because you can cast any pointer-pair >>> to char *, subtract them and use the difference for memcpy(). >> >> This holds only for linear memory model. While this is a dominant >> memory model nowadays, the C++ language is old enough to take also >> other memory models (like segmented ones) into account. In segmented >> memory models, pointer arithmetic only works in a single segment, and >> accordingly the arrays are limited to a single segment. There is no >> such limitation for struct members. > > In C there is, because any object can be treated as an array > of character type, and that includes structs. > > In C++ the rules are so complicated that no one knows whether > that reasoning applies, so the safest course of action is not > to use C++ on machines that use segmentation. I'm pretty sure that any C++ implementations on segmented architectures would require also structs and classes to fit in a single segment, it's much easier that way. Anyway, this is not really important because Bonita talked about "any pair of pointers", no mention of structs was made. When you take one pointer from say DS segment and the other from ES segment, then calculating their difference might not have any meaning for the program, not to speak about fitting this difference into a size_t variable or copying this memory range somewhere. At best you could copy a tail of the DS segment and the head of the ES segment somewhere, but why not vice versa?
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-06-10 11:29 -0700 |
| Message-ID | <86lf7hd146.fsf@linuxsc.com> |
| In reply to | #80220 |
Paavo Helde <myfirstname@osa.pri.ee> writes: > 07.06.2021 19:19 Tim Rentsch kirjutas: > >> Paavo Helde <myfirstname@osa.pri.ee> writes: >> >>> 05.06.2021 16:06 Bonita Montero kirjutas: >>> >>>>> No. Subtraction of pointers is defined as the difference in their >>>>> indexes within a single array. >>>> >>>> That coudn't be true because you can cast any pointer-pair >>>> to char *, subtract them and use the difference for memcpy(). >>> >>> This holds only for linear memory model. While this is a dominant >>> memory model nowadays, the C++ language is old enough to take also >>> other memory models (like segmented ones) into account. In segmented >>> memory models, pointer arithmetic only works in a single segment, and >>> accordingly the arrays are limited to a single segment. There is no >>> such limitation for struct members. >> >> In C there is, because any object can be treated as an array >> of character type, and that includes structs. >> >> In C++ the rules are so complicated that no one knows whether >> that reasoning applies, so the safest course of action is not >> to use C++ on machines that use segmentation. > > I'm pretty sure that any C++ implementations on segmented > architectures would require also structs and classes to fit in a > single segment, it's much easier that way. > > Anyway, this is not really important because Bonita talked about "any > pair of pointers", no mention of structs was made. > > When you take one pointer from say DS segment and the other from ES > segment, then calculating their difference might not have any meaning > for the program, not to speak about fitting this difference into a > size_t variable or copying this memory range somewhere. At best you > could copy a tail of the DS segment and the head of the ES segment > somewhere, but why not vice versa? Yes, as a practical matter no actual C++ implementation is going to accommodate objects that cross a segment boundary. My question though was about what the C++ standard allows for pointers into a single struct object (of the contiguous variety). I know that C does allow pointer arithmetic for such pointers (ie, character pointers), but my efforts to discover whether the C++ standard allows it have not been successful.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2021-06-05 05:38 -0700 |
| Message-ID | <dbfb7969-4661-40d3-8926-0a87de59fce1n@googlegroups.com> |
| In reply to | #80157 |
On Saturday, 5 June 2021 at 15:20:07 UTC+3, David Brown wrote:
> On 05/06/2021 12:53, Bonita Montero wrote:
> > Consider the following code:
> >
> >
> > size_t s( int *begin, int *end )
> > {
> > return (end - begin) * sizeof(int);
> > }
> >
> > This is MSVC's disassembly:
> >
> > sub rdx, rcx
> > and rdx, -4
> > mov rax, rdx
> > ret 0
> >
> > This is gcc's disassembly:
> >
> > movq %rsi, %rax
> > subq %rdi, %rax
> > ret
> >
> > It the masking really necessary or just an optimizer weakness;
> > it seems to me MSVC sees that two bits are shifted out and "in"
> > and replaces this with a mask.
> > I think that the language-standard assumes equally aligned data
> > among same types for the above code and gcc is corcect, but I'm
> > not sure.
> >
> I can't help thinking that putting a non-aligned value into an int
> pointer is undefined behaviour - but I can't find a reference to that in
> the C standards (and I don't know the C++ standards well enough to look
> there).
The C and C++ programs that use unaligned pointers are undefined (in
sense of standard) regardless of the target architecture (that may allow
unaligned accesses) but the implementations can extend.
> However, when you subtract two pointers, the behaviour is only
> defined if they both point to elements inside the same array (or one
> past the end). It doesn't matter how they are aligned, as the offset
> from the standard "int" alignment will be the same for both pointers.
> (This applies also to 8-bit systems where you might have 16-bit int but
> 8-bit alignment for int.) Thus gcc's code is fine.
Also MS code is fine as that masking should not have any ill effects
to conforming code.
> MSVC has a tradition of being more conservative in its optimisations,
> while gcc has a tradition of expecting people to write valid code and
> optimise on the assumption that undefined behaviour does not occur.
> This is, I think, because MSDOS and Windows programmers have a tradition
> of assuming their code runs on one platform and one compiler, and "it
> worked when I tested it" means "it is correct". (Your own misstatements
> about undefined behaviour have demonstrated that.) gcc users are more
> likely to understand that their code could be used on different
> platforms and different processors, and pay a bit more attention to the
> rules of the language.
I think that most important requirement of MSVC is that it should build
good binaries out of Microsoft's own code base regardless how tricky
that code base is. The gcc as whole does not have that sort of obligations.
Perhaps some people working on gcc code base have but they are from
wide variety of companies.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-06-05 15:41 +0200 |
| Message-ID | <s9fuu0$pc3$1@dont-email.me> |
| In reply to | #80160 |
On 05/06/2021 14:38, Öö Tiib wrote:
> On Saturday, 5 June 2021 at 15:20:07 UTC+3, David Brown wrote:
>> On 05/06/2021 12:53, Bonita Montero wrote:
>>> Consider the following code:
>>>
>>>
>>> size_t s( int *begin, int *end )
>>> {
>>> return (end - begin) * sizeof(int);
>>> }
>>>
>>> This is MSVC's disassembly:
>>>
>>> sub rdx, rcx
>>> and rdx, -4
>>> mov rax, rdx
>>> ret 0
>>>
>>> This is gcc's disassembly:
>>>
>>> movq %rsi, %rax
>>> subq %rdi, %rax
>>> ret
>>>
>>> It the masking really necessary or just an optimizer weakness;
>>> it seems to me MSVC sees that two bits are shifted out and "in"
>>> and replaces this with a mask.
>>> I think that the language-standard assumes equally aligned data
>>> among same types for the above code and gcc is corcect, but I'm
>>> not sure.
>>>
>> I can't help thinking that putting a non-aligned value into an int
>> pointer is undefined behaviour - but I can't find a reference to that in
>> the C standards (and I don't know the C++ standards well enough to look
>> there).
>
> The C and C++ programs that use unaligned pointers are undefined (in
> sense of standard) regardless of the target architecture (that may allow
> unaligned accesses) but the implementations can extend.
>
Of course implementations can add whatever definitions they want beyond
the requirements of the standard.
And while dereferencing unaligned pointers is undefined behaviour (by
the standards), I haven't found anything that says that merely assigning
an unaligned value to a pointer is undefined behaviour. But that could
easily be something I missed - hopefully someone can then give the
reference (in the C or C++ standards).
>> However, when you subtract two pointers, the behaviour is only
>> defined if they both point to elements inside the same array (or one
>> past the end). It doesn't matter how they are aligned, as the offset
>> from the standard "int" alignment will be the same for both pointers.
>> (This applies also to 8-bit systems where you might have 16-bit int but
>> 8-bit alignment for int.) Thus gcc's code is fine.
>
> Also MS code is fine as that masking should not have any ill effects
> to conforming code.
>
Sure. Suboptimal, but correct.
>> MSVC has a tradition of being more conservative in its optimisations,
>> while gcc has a tradition of expecting people to write valid code and
>> optimise on the assumption that undefined behaviour does not occur.
>> This is, I think, because MSDOS and Windows programmers have a tradition
>> of assuming their code runs on one platform and one compiler, and "it
>> worked when I tested it" means "it is correct". (Your own misstatements
>> about undefined behaviour have demonstrated that.) gcc users are more
>> likely to understand that their code could be used on different
>> platforms and different processors, and pay a bit more attention to the
>> rules of the language.
>
> I think that most important requirement of MSVC is that it should build
> good binaries out of Microsoft's own code base regardless how tricky
> that code base is.
That is a reasonable requirement!
> The gcc as whole does not have that sort of obligations.
gcc needs to be able to compile gcc and all its dependencies, libraries,
etc. That in itself is a rather massive and complex code base, full of
all kinds of weird stuff for historic reasons (including garbage
collection, mixes of C and C++, and code that dates back 30+ years that
no one really understands).
They also work with the Linux kernel folk and distributions like Debian
to test on a huge variety of existing software. I'm not sure whether
you could call that an "obligation" or a "requirement" for gcc as a
whole or, as you say, just for some people working on gcc. But it is
certainly something they do in the process of testing and preparing
releases.
> Perhaps some people working on gcc code base have but they are from
> wide variety of companies.
>
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2021-06-05 08:18 -0700 |
| Message-ID | <d2d4c09e-eaeb-406a-96ce-8441c65fc12en@googlegroups.com> |
| In reply to | #80164 |
On Saturday, 5 June 2021 at 16:41:35 UTC+3, David Brown wrote:
> On 05/06/2021 14:38, Öö Tiib wrote:
> > On Saturday, 5 June 2021 at 15:20:07 UTC+3, David Brown wrote:
> >> On 05/06/2021 12:53, Bonita Montero wrote:
> >>> Consider the following code:
> >>>
> >>>
> >>> size_t s( int *begin, int *end )
> >>> {
> >>> return (end - begin) * sizeof(int);
> >>> }
> >>>
> >>> This is MSVC's disassembly:
> >>>
> >>> sub rdx, rcx
> >>> and rdx, -4
> >>> mov rax, rdx
> >>> ret 0
> >>>
> >>> This is gcc's disassembly:
> >>>
> >>> movq %rsi, %rax
> >>> subq %rdi, %rax
> >>> ret
> >>>
> >>> It the masking really necessary or just an optimizer weakness;
> >>> it seems to me MSVC sees that two bits are shifted out and "in"
> >>> and replaces this with a mask.
> >>> I think that the language-standard assumes equally aligned data
> >>> among same types for the above code and gcc is corcect, but I'm
> >>> not sure.
> >>>
> >> I can't help thinking that putting a non-aligned value into an int
> >> pointer is undefined behaviour - but I can't find a reference to that in
> >> the C standards (and I don't know the C++ standards well enough to look
> >> there).
> >
> > The C and C++ programs that use unaligned pointers are undefined (in
> > sense of standard) regardless of the target architecture (that may allow
> > unaligned accesses) but the implementations can extend.
> >
> Of course implementations can add whatever definitions they want beyond
> the requirements of the standard.
>
> And while dereferencing unaligned pointers is undefined behaviour (by
> the standards), I haven't found anything that says that merely assigning
> an unaligned value to a pointer is undefined behaviour. But that could
> easily be something I missed - hopefully someone can then give the
> reference (in the C or C++ standards).
When to attempt to make the pointer that is unaligned then "resulting
pointer value is unspecified" or equal wording in couple places of
C++ standard. I did mean usage like dereferencing of such unspecified
pointer value is undefined (unless implementation gives some better
guarantees).
> >> MSVC has a tradition of being more conservative in its optimisations,
> >> while gcc has a tradition of expecting people to write valid code and
> >> optimise on the assumption that undefined behaviour does not occur.
> >> This is, I think, because MSDOS and Windows programmers have a tradition
> >> of assuming their code runs on one platform and one compiler, and "it
> >> worked when I tested it" means "it is correct". (Your own misstatements
> >> about undefined behaviour have demonstrated that.) gcc users are more
> >> likely to understand that their code could be used on different
> >> platforms and different processors, and pay a bit more attention to the
> >> rules of the language.
> >
> > I think that most important requirement of MSVC is that it should build
> > good binaries out of Microsoft's own code base regardless how tricky
> > that code base is.
>
> That is a reasonable requirement!
>
> > The gcc as whole does not have that sort of obligations.
>
> gcc needs to be able to compile gcc and all its dependencies, libraries,
> etc. That in itself is a rather massive and complex code base, full of
> all kinds of weird stuff for historic reasons (including garbage
> collection, mixes of C and C++, and code that dates back 30+ years that
> no one really understands).
I agree. Still in MS if a code that did run with compiler version A does not
run with with compiler version B then it is about what is cheaper to
business: (1) to fix undefined behavior in that code or (2) to adjust that
compiler B. That (2) is more common with msvc than with gcc that also
compiles undefined behaviors in popular benchmarks "correctly" (as
example of (2) with gcc).
> They also work with the Linux kernel folk and distributions like Debian
> to test on a huge variety of existing software. I'm not sure whether
> you could call that an "obligation" or a "requirement" for gcc as a
> whole or, as you say, just for some people working on gcc. But it is
> certainly something they do in the process of testing and preparing
> releases.
That code-base can't be declared sacred by business or by being
popular benchmark. So there we see Linus being vulgar but complying
and fixing such legacy code.
[toc] | [prev] | [next] | [standalone]
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
Back to top | Article view | comp.lang.c++
csiph-web