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 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-08-11 14:01 +0000 |
| Message-ID | <gLQQI.17282$lK.16700@fx41.iad> |
| In reply to | #80843 |
Juha Nieminen <nospam@thanks.invalid> writes: >Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >> Vir Campestris <vir.campestris@invalid.invalid> writes: >> >> [..stuff about 64 bit systems removed..] >> >>> What bothers me about ptr_diff_t is the size. The difference between >>> two 32-bit pointers is plus or minus 4GB. Which needs a 33 bit value >>> :( >>> >>> As it happens it's never been a practical problem as I've never had a >>> 32 bit system with more than 2GB RAM, >> >> It isn't necessary for there to be more than 2GB of RAM for >> problems with ptrdiff_t to manifest (in 32-bit linux). A call to >> malloc() will gladly return a memory area larger than all of RAM >> if there is swap space to hold it. > >Also, doesn't mmap() in Linux map a file into "virtual memory"? >Ostensibly this can be larger than the amount of physical RAM. mmap() maps a file into the application address space. For operating environments that run with address virtualization, such as the typical intel/amd/arm processors, the backing store for the pages is the original file itself. As with any virtual memory system, pressure on the physical address space will result in movement of pages between memory and backing store as required. mmap() can also map "anonymous" space, in which case swap space is allocated as backing store for the virtual addresses allocated by the mmap() system call.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-08-09 23:20 -0400 |
| Message-ID | <sesr9s$b6p$1@dont-email.me> |
| In reply to | #80807 |
On 8/9/21 12:23 PM, MrSpud_HG@_0b772d8ha3yjo0xb.edu wrote: > On Mon, 9 Aug 2021 12:16:46 -0400 > James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >> On 8/9/21 4:19 AM, MrSpud_ifhov@nldls6_1kg3nl2qnwv.biz wrote: >>> On Sun, 8 Aug 2021 09:23:46 -0400 >>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >>> Then don't use ptrdiff_t. I suspect like most people I wasn't even aware >>> it existed. >> >> I hope you're wrong about that - it's a fairly basic aspect of C, like >> [u]intptr_t or size_t. But my degree was in Physics, not CS, so I don't >> have any idea how bad the average CS major's education might have been. > > Ooo look at you, supercilious and patronising all in one go. Well done,have > a scooby snack. I'm sorry - people who confess to being unfamiliar with fairly basic aspects of C tend to produce feelings of superiority in me. >> If you never need to store the result of pointer subtractions, there's >> no need to use ptrdiff_t. If you're calculating the difference between >> pointers, and know enough about the calculation to at least roughly > > Any parser beyond the most basic needs to do pointer arithmetic and I've > written a LOT of them. Unless your parsers were successfully ported to the kinds of platforms I was talking about, that's not particularly relevant to the point I was making. >> type to store the result. ptrdiff_t is needed only if you have no other >> information to go on about the size of a pointer difference that you >> need to store - and if ptrdiff_t cannot represent such a value, it's >> likely to be the case that there is no integer type supported by that >> implementation that can. If there were such a type, it would have been >> used as ptrdiff_t. > > I should have clarified in my origional post that I was refering to programming > in grown up OS's on grown up CPUs. Not on DOS with 1970s x86 segmentation. As I said, I'm not personally familiar with such platforms, but the impression I get is that they tend to be small embedded CPUs - which would explain my total lack of familiarity with them. Embedded programming is a large and rapidly growing part of the C/C++ programming world, but one that has never played any part in any job I've ever held. >>> So long as mathematical operations can be done on the pointer types (which >>> is a given or they'd be no use as pointers) then they are de facto integer >>> types and that statement is wrong. >> >> Yes, but when these issues come into play, the relevant mathematical >> operations cannot be done on pointer types. The result of a pointer > > They can in *nix which is good enough for me. Yes, but the intended scope of the C++ standard is considerably broader than what's good enough for you.
[toc] | [prev] | [next] | [standalone]
| From | MrSpud_m7k7yilq_8@u6w.biz |
|---|---|
| Date | 2021-08-10 07:26 +0000 |
| Message-ID | <set9o0$u28$1@gioia.aioe.org> |
| In reply to | #80813 |
On Mon, 9 Aug 2021 23:20:27 -0400 James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >On 8/9/21 12:23 PM, MrSpud_HG@_0b772d8ha3yjo0xb.edu wrote: >> On Mon, 9 Aug 2021 12:16:46 -0400 >> James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >>> On 8/9/21 4:19 AM, MrSpud_ifhov@nldls6_1kg3nl2qnwv.biz wrote: >>>> On Sun, 8 Aug 2021 09:23:46 -0400 >>>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >>>> Then don't use ptrdiff_t. I suspect like most people I wasn't even aware >>>> it existed. >>> >>> I hope you're wrong about that - it's a fairly basic aspect of C, like >>> [u]intptr_t or size_t. But my degree was in Physics, not CS, so I don't >>> have any idea how bad the average CS major's education might have been. >> >> Ooo look at you, supercilious and patronising all in one go. Well done,have >> a scooby snack. > >I'm sorry - people who confess to being unfamiliar with fairly basic >aspects of C tend to produce feelings of superiority in me. In 25 years I've never ever seen that type used so spare me your BS. The only ones with misplaced feelings of superiority is you. >> Any parser beyond the most basic needs to do pointer arithmetic and I've >> written a LOT of them. > >Unless your parsers were successfully ported to the kinds of platforms I >was talking about, that's not particularly relevant to the point I was >making. They've been used on x86 and ARM on various OS's. >As I said, I'm not personally familiar with such platforms, but the >impression I get is that they tend to be small embedded CPUs - which >would explain my total lack of familiarity with them. Embedded >programming is a large and rapidly growing part of the C/C++ programming >world, but one that has never played any part in any job I've ever held. Unless you're using some prehistoric 16 bit (or less) PIC then all pointers in embedded C will be 32 bit linear.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-08-10 07:51 +0000 |
| Message-ID | <setb6s$1hbl$1@gioia.aioe.org> |
| In reply to | #80817 |
MrSpud_m7k7yilq_8@u6w.biz wrote: > In 25 years I've never ever seen that type used so spare me your BS. The only > ones with misplaced feelings of superiority is you. I think that you know perfectly well that with that kind of hostile language and attitude you are not going to persuade anybody, nor are you going to get much support, neither from the person you are talking to, nor pretty much anybody else. Thus, I think you know perfectly well that by using that kind of language and attitude, you are making a pariah of yourself here. You could express your statements in a neutral way, but instead you willingly choose to denigrate people and be very antagonistic. So I have to wonder why. What psychological issue makes you want to become a hated pariah? Why do you willingly antagonize people? Why do you want them to find you disgusting and unlikeable? Is it to get some kind of sense of being a victim, a martyr? Perhaps some self-reflection could do you some good. In the long run, being nicer will make also you yourself happier.
[toc] | [prev] | [next] | [standalone]
| From | MrSpud_ggBp1lq0@lxz.tv |
|---|---|
| Date | 2021-08-10 07:59 +0000 |
| Message-ID | <setbkt$1n4g$1@gioia.aioe.org> |
| In reply to | #80819 |
On Tue, 10 Aug 2021 07:51:58 -0000 (UTC) Juha Nieminen <nospam@thanks.invalid> wrote: >MrSpud_m7k7yilq_8@u6w.biz wrote: >> In 25 years I've never ever seen that type used so spare me your BS. The >only >> ones with misplaced feelings of superiority is you. > >I think that you know perfectly well that with that kind of hostile language >and attitude you are not going to persuade anybody, nor are you going to get >much support, neither from the person you are talking to, nor pretty much >anybody else. Thus, I think you know perfectly well that by using that kind >of language and attitude, you are making a pariah of yourself here. Ah, a nice bit of early morning irony to go with my coffee :) >You could express your statements in a neutral way, but instead you >willingly choose to denigrate people and be very antagonistic. I suggest you read what he wrote. I'm simply replying in kind. >So I have to wonder why. What psychological issue makes you want to become >a hated pariah? Why do you willingly antagonize people? Why do you want >them to find you disgusting and unlikeable? Is it to get some kind of >sense of being a victim, a martyr? If you wish to try out your cod psychology I would suggest you get at least a vague clue first. >Perhaps some self-reflection could do you some good. In the long run, >being nicer will make also you yourself happier. Aww, bless you :)
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-08-10 12:24 +0000 |
| Message-ID | <setr6a$nj3$1@gioia.aioe.org> |
| In reply to | #80820 |
MrSpud_ggBp1lq0@lxz.tv wrote: > If you wish to try out your cod psychology I would suggest you get at least > a vague clue first. > >>Perhaps some self-reflection could do you some good. In the long run, >>being nicer will make also you yourself happier. > > Aww, bless you :) It's not surprising that you would struggle against this kind of advise, but perhaps some time in the next years you will think about it more seriously. Being nice and polite to people is genuinely more rewarding and gives yourself more happiness in the long run than being rude, aggressive and confrontational, which will just make you miserable in the long run. Mockery might give you immediate satisfaction, but in the long run it's just going to destroy your own happiness. You might not believe it now, but you will believe it eventually. Just think about it. It's never too late to learn and change.
[toc] | [prev] | [next] | [standalone]
| From | MrSpud_u7lm@bxuc3wy1g3cxiqu5j2x1_7iu.com |
|---|---|
| Date | 2021-08-10 15:51 +0000 |
| Message-ID | <seu79v$gk9$1@gioia.aioe.org> |
| In reply to | #80822 |
On Tue, 10 Aug 2021 12:24:44 -0000 (UTC) Juha Nieminen <nospam@thanks.invalid> wrote: >MrSpud_ggBp1lq0@lxz.tv wrote: >> If you wish to try out your cod psychology I would suggest you get at least >> a vague clue first. >> >>>Perhaps some self-reflection could do you some good. In the long run, >>>being nicer will make also you yourself happier. >> >> Aww, bless you :) > >It's not surprising that you would struggle against this kind of advise, >but perhaps some time in the next years you will think about it more >seriously. > >Being nice and polite to people is genuinely more rewarding and gives >yourself more happiness in the long run than being rude, aggressive and >confrontational, which will just make you miserable in the long run. Take your own advice hypocrit. The fact that you flip flop between being some kind of comedy psychologist and a rude prick tells me that you're almost certainly suffering either from severe stress or you're bipolar.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-08-11 05:47 +0000 |
| Message-ID | <sevo97$djr$3@gioia.aioe.org> |
| In reply to | #80837 |
MrSpud_u7lm@bxuc3wy1g3cxiqu5j2x1_7iu.com wrote: > On Tue, 10 Aug 2021 12:24:44 -0000 (UTC) > Juha Nieminen <nospam@thanks.invalid> wrote: >>MrSpud_ggBp1lq0@lxz.tv wrote: >>> If you wish to try out your cod psychology I would suggest you get at least >>> a vague clue first. >>> >>>>Perhaps some self-reflection could do you some good. In the long run, >>>>being nicer will make also you yourself happier. >>> >>> Aww, bless you :) >> >>It's not surprising that you would struggle against this kind of advise, >>but perhaps some time in the next years you will think about it more >>seriously. >> >>Being nice and polite to people is genuinely more rewarding and gives >>yourself more happiness in the long run than being rude, aggressive and >>confrontational, which will just make you miserable in the long run. > > Take your own advice hypocrit. The fact that you flip flop between being > some kind of comedy psychologist and a rude prick tells me that you're almost > certainly suffering either from severe stress or you're bipolar. Even if any of that were true, so what? Do you call an alcoholic a hypocrite for warning you about the dangers of alcohol? "Don't make the same mistakes I have made" is not hypocrisy.
[toc] | [prev] | [next] | [standalone]
| From | mickspud@downthefarm.com |
|---|---|
| Date | 2021-08-11 08:46 +0000 |
| Message-ID | <sf02p0$otm$1@gioia.aioe.org> |
| In reply to | #80844 |
On Wed, 11 Aug 2021 05:47:21 -0000 (UTC) Juha Nieminen <nospam@thanks.invalid> wrote: >MrSpud_u7lm@bxuc3wy1g3cxiqu5j2x1_7iu.com wrote: >> On Tue, 10 Aug 2021 12:24:44 -0000 (UTC) >> Juha Nieminen <nospam@thanks.invalid> wrote: >>>MrSpud_ggBp1lq0@lxz.tv wrote: >>>> If you wish to try out your cod psychology I would suggest you get at least > >>>> a vague clue first. >>>> >>>>>Perhaps some self-reflection could do you some good. In the long run, >>>>>being nicer will make also you yourself happier. >>>> >>>> Aww, bless you :) >>> >>>It's not surprising that you would struggle against this kind of advise, >>>but perhaps some time in the next years you will think about it more >>>seriously. >>> >>>Being nice and polite to people is genuinely more rewarding and gives >>>yourself more happiness in the long run than being rude, aggressive and >>>confrontational, which will just make you miserable in the long run. >> >> Take your own advice hypocrit. The fact that you flip flop between being >> some kind of comedy psychologist and a rude prick tells me that you're almost > >> certainly suffering either from severe stress or you're bipolar. > >Even if any of that were true, so what? Do you call an alcoholic a hypocrite >for warning you about the dangers of alcohol? If an alcoholic who went around swearing and cursing at people told me I shouldn't swear and curse I'll tell him to bugger off and sort himself out first.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-08-10 11:20 +0200 |
| Message-ID | <setgdk$f1a$1@dont-email.me> |
| In reply to | #80817 |
On 10/08/2021 09:26, MrSpud_m7k7yilq_8@u6w.biz wrote: > On Mon, 9 Aug 2021 23:20:27 -0400 > James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >> As I said, I'm not personally familiar with such platforms, but the >> impression I get is that they tend to be small embedded CPUs - which >> would explain my total lack of familiarity with them. Embedded >> programming is a large and rapidly growing part of the C/C++ programming >> world, but one that has never played any part in any job I've ever held. > > Unless you're using some prehistoric 16 bit (or less) PIC then all pointers in > embedded C will be 32 bit linear. > That makes it clear that you are so ignorant about the world outside of *nix that you have no idea how ignorant you are. If all your programming world is within the specific segment of *nix systems, that's fine - lucky you, some might say. But please understand there is a world outside of that, where C and C++ are heavily used but many of the assumptions you make do not hold. You'd do well to learn from James here - he knows little about the world of small-system embedded programming, but he /knows/ he knows little about it - he knows it is important, and knows it can be different from the systems he usually works with, and knows it is one of the reasons for some of the flexibilities in the C and C++ standards.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-08-10 10:27 -0400 |
| Message-ID | <seu2d2$6t6$1@dont-email.me> |
| In reply to | #80821 |
On 8/10/21 5:20 AM, David Brown wrote: > On 10/08/2021 09:26, MrSpud_m7k7yilq_8@u6w.biz wrote: >> On Mon, 9 Aug 2021 23:20:27 -0400 >> James Kuyper <jameskuyper@alumni.caltech.edu> wrote: > >>> As I said, I'm not personally familiar with such platforms, but the >>> impression I get is that they tend to be small embedded CPUs - which >>> would explain my total lack of familiarity with them. Embedded >>> programming is a large and rapidly growing part of the C/C++ programming >>> world, but one that has never played any part in any job I've ever held. >> >> Unless you're using some prehistoric 16 bit (or less) PIC then all pointers in >> embedded C will be 32 bit linear. >> > > That makes it clear that you are so ignorant about the world outside of > *nix that you have no idea how ignorant you are. If all your > programming world is within the specific segment of *nix systems, that's > fine - lucky you, some might say. But please understand there is a > world outside of that, where C and C++ are heavily used but many of the > assumptions you make do not hold. > > You'd do well to learn from James here - he knows little about the world > of small-system embedded programming, but he /knows/ he knows little > about it - he knows it is important, and knows it can be different from > the systems he usually works with, and knows it is one of the reasons > for some of the flexibilities in the C and C++ standards. I was hoping someone with more relevant experience would respond. However, I was, in particular, hoping someone would respond with an example. Do you know of any particular modern system, preferably as widely used as possible, where ptrdiff_t was not big enough to store all possible pointer differences, or where [u]intptr_t is not supported?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-08-10 17:44 +0200 |
| Message-ID | <seu6t8$mc$1@dont-email.me> |
| In reply to | #80828 |
On 10/08/2021 16:27, James Kuyper wrote: > On 8/10/21 5:20 AM, David Brown wrote: >> On 10/08/2021 09:26, MrSpud_m7k7yilq_8@u6w.biz wrote: >>> On Mon, 9 Aug 2021 23:20:27 -0400 >>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >> >>>> As I said, I'm not personally familiar with such platforms, but the >>>> impression I get is that they tend to be small embedded CPUs - which >>>> would explain my total lack of familiarity with them. Embedded >>>> programming is a large and rapidly growing part of the C/C++ programming >>>> world, but one that has never played any part in any job I've ever held. >>> >>> Unless you're using some prehistoric 16 bit (or less) PIC then all pointers in >>> embedded C will be 32 bit linear. >>> >> >> That makes it clear that you are so ignorant about the world outside of >> *nix that you have no idea how ignorant you are. If all your >> programming world is within the specific segment of *nix systems, that's >> fine - lucky you, some might say. But please understand there is a >> world outside of that, where C and C++ are heavily used but many of the >> assumptions you make do not hold. >> >> You'd do well to learn from James here - he knows little about the world >> of small-system embedded programming, but he /knows/ he knows little >> about it - he knows it is important, and knows it can be different from >> the systems he usually works with, and knows it is one of the reasons >> for some of the flexibilities in the C and C++ standards. > > I was hoping someone with more relevant experience would respond. > However, I was, in particular, hoping someone would respond with an > example. Do you know of any particular modern system, preferably as > widely used as possible, where ptrdiff_t was not big enough to store all > possible pointer differences, or where [u]intptr_t is not supported? > I know of a system where ptrdiff_t is, like size_t, 16-bit - but where there are pointer types that are 24-bit. The gcc port for the AVR is my usual first choice of example here, since it is a gcc target and the microcontrollers concerned are in common use, with new devices being developed on a regular basis. (i.e., they are not some brain-dead outdated cpu with only sort-of-C compilers such as the 8051 or 8086 - these are modern devices with modern C and C++ tools, albeit with only limited language support libraries for C++). In particular, comparing (or subtracting) pointers from different address spaces is completely meaningless, and if you have two 24-bit "__memx" pointers that target different physical memory types in the chip, then subtracting them is not going to fit in a 16-bit ptrdiff_t. <https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html> For most C and C++ implementations, ptrdiff_t is a signed type of the same width as the full address space of the device (ignoring devices like the AVR with multiple independent address spaces). If you have full control over the linking setup and other aspects of making a binary for the device - as you often do for freestanding embedded code - you can easily construct arrays that are bigger than half the address space. Subtracting a pointer to the first element of such an array from a pointer to its last object will give you an integer result that is too big for ptrdiff_t. There is no constraint error, but it is undefined behaviour (6.5.6p9). A quick test using godbolt.org with 32-bit ARM compilers shows that gcc will not compile "extern char data[0xc0000000];", but clang for these devices accepts it. ptrdiff_t, however, is not big enough to store the differences between all pointers to elements within that one array. I don't know of any systems where uintptr_t does not exist, sorry. Perhaps some "capability pointer" systems would count, but I am not at all familiar with them.
[toc] | [prev] | [next] | [standalone]
| From | MrSpud_885p_dugji@l6zhsgj_v6t3dbj.tv |
|---|---|
| Date | 2021-08-10 15:50 +0000 |
| Message-ID | <seu77i$fjq$1@gioia.aioe.org> |
| In reply to | #80821 |
On Tue, 10 Aug 2021 11:20:52 +0200 David Brown <david.brown@hesbynett.no> wrote: >On 10/08/2021 09:26, MrSpud_m7k7yilq_8@u6w.biz wrote: >> On Mon, 9 Aug 2021 23:20:27 -0400 >> James Kuyper <jameskuyper@alumni.caltech.edu> wrote: > >>> As I said, I'm not personally familiar with such platforms, but the >>> impression I get is that they tend to be small embedded CPUs - which >>> would explain my total lack of familiarity with them. Embedded >>> programming is a large and rapidly growing part of the C/C++ programming >>> world, but one that has never played any part in any job I've ever held. >> >> Unless you're using some prehistoric 16 bit (or less) PIC then all pointers >in >> embedded C will be 32 bit linear. >> > >That makes it clear that you are so ignorant about the world outside of >*nix that you have no idea how ignorant you are. If all your Oh ok. I guess all my PIC development not to mention arduino counts for nothing then? If you say so.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-08-11 08:31 +0200 |
| Message-ID | <sevqri$9v$1@dont-email.me> |
| In reply to | #80836 |
On 10/08/2021 17:50, MrSpud_885p_dugji@l6zhsgj_v6t3dbj.tv wrote: > On Tue, 10 Aug 2021 11:20:52 +0200 > David Brown <david.brown@hesbynett.no> wrote: >> On 10/08/2021 09:26, MrSpud_m7k7yilq_8@u6w.biz wrote: >>> On Mon, 9 Aug 2021 23:20:27 -0400 >>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >> >>>> As I said, I'm not personally familiar with such platforms, but the >>>> impression I get is that they tend to be small embedded CPUs - which >>>> would explain my total lack of familiarity with them. Embedded >>>> programming is a large and rapidly growing part of the C/C++ programming >>>> world, but one that has never played any part in any job I've ever held. >>> >>> Unless you're using some prehistoric 16 bit (or less) PIC then all pointers >> in >>> embedded C will be 32 bit linear. >>> >> >> That makes it clear that you are so ignorant about the world outside of >> *nix that you have no idea how ignorant you are. If all your > > Oh ok. I guess all my PIC development not to mention arduino counts for > nothing then? If you say so. > Apparently, yes. Certainly you don't appear to have learned anything. However, I think I will be taking the common advice here and basically ignoring you, for the good of the group. Feel free to reply with some sort of insult if it makes you feel better.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-08-10 10:27 -0400 |
| Message-ID | <seu2c3$6a1$1@dont-email.me> |
| In reply to | #80817 |
On 8/10/21 3:26 AM, MrSpud_m7k7yilq_8@u6w.biz wrote: > On Mon, 9 Aug 2021 23:20:27 -0400 > James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >> On 8/9/21 12:23 PM, MrSpud_HG@_0b772d8ha3yjo0xb.edu wrote: ... >>> Any parser beyond the most basic needs to do pointer arithmetic and I've >>> written a LOT of them. >> >> Unless your parsers were successfully ported to the kinds of platforms I >> was talking about, that's not particularly relevant to the point I was >> making. > > They've been used on x86 and ARM on various OS's. So, not the kinds of platforms I was talking about. Keep in mind that you'd only run into trouble doing pointer arithmetic on pointers into arrays with more than PTRDIFF_MAX elements. Did your parsers ever need to parse something that big? PTRDIFF_MAX is required to be at least 65535, but it's the actual value on the platform you're compiling for that matters.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-08-10 11:27 -0700 |
| Message-ID | <87a6lpf94r.fsf@nosuchdomain.example.com> |
| In reply to | #80817 |
MrSpud_m7k7yilq_8@u6w.biz writes:
> On Mon, 9 Aug 2021 23:20:27 -0400
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>On 8/9/21 12:23 PM, MrSpud_HG@_0b772d8ha3yjo0xb.edu wrote:
>>> On Mon, 9 Aug 2021 12:16:46 -0400
>>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>>> On 8/9/21 4:19 AM, MrSpud_ifhov@nldls6_1kg3nl2qnwv.biz wrote:
>>>>> On Sun, 8 Aug 2021 09:23:46 -0400
>>>>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>>>> Then don't use ptrdiff_t. I suspect like most people I wasn't even aware
>>>>> it existed.
>>>>
>>>> I hope you're wrong about that - it's a fairly basic aspect of C, like
>>>> [u]intptr_t or size_t. But my degree was in Physics, not CS, so I don't
>>>> have any idea how bad the average CS major's education might have been.
>>>
>>> Ooo look at you, supercilious and patronising all in one go. Well done,have
>>> a scooby snack.
>>
>>I'm sorry - people who confess to being unfamiliar with fairly basic
>>aspects of C tend to produce feelings of superiority in me.
>
> In 25 years I've never ever seen that type used
[snip]
If you've done pointer subtraction in C or C++, you've used ptrdiff_t.
You might not have referred to it by that name.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | mickspud@downthefarm.com |
|---|---|
| Date | 2021-08-11 08:44 +0000 |
| Message-ID | <sf02lr$nqb$1@gioia.aioe.org> |
| In reply to | #80839 |
On Tue, 10 Aug 2021 11:27:16 -0700 Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >MrSpud_m7k7yilq_8@u6w.biz writes: >> On Mon, 9 Aug 2021 23:20:27 -0400 >> James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >>>On 8/9/21 12:23 PM, MrSpud_HG@_0b772d8ha3yjo0xb.edu wrote: >>>> On Mon, 9 Aug 2021 12:16:46 -0400 >>>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >>>>> On 8/9/21 4:19 AM, MrSpud_ifhov@nldls6_1kg3nl2qnwv.biz wrote: >>>>>> On Sun, 8 Aug 2021 09:23:46 -0400 >>>>>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >>>>>> Then don't use ptrdiff_t. I suspect like most people I wasn't even aware >>>>>> it existed. >>>>> >>>>> I hope you're wrong about that - it's a fairly basic aspect of C, like >>>>> [u]intptr_t or size_t. But my degree was in Physics, not CS, so I don't >>>>> have any idea how bad the average CS major's education might have been. >>>> >>>> Ooo look at you, supercilious and patronising all in one go. Well done,have > >>>> a scooby snack. >>> >>>I'm sorry - people who confess to being unfamiliar with fairly basic >>>aspects of C tend to produce feelings of superiority in me. >> >> In 25 years I've never ever seen that type used >[snip] > >If you've done pointer subtraction in C or C++, you've used ptrdiff_t. >You might not have referred to it by that name. If its typedef'd to a long then yes.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-08-11 16:05 +0300 |
| Message-ID | <sf0huq$li9$1@dont-email.me> |
| In reply to | #80846 |
11.08.2021 11:44 mickspud@downthefarm.com kirjutas: > On Tue, 10 Aug 2021 11:27:16 -0700 > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >> If you've done pointer subtraction in C or C++, you've used ptrdiff_t. >> You might not have referred to it by that name. > > If its typedef'd to a long then yes. > Using 'long' for storing pointer differences is error-prone and may easily fail in current x64 Windows where long has the same size as int. Better use a type meant for storing pointer differences, i.e. ptrdiff_t.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-08-10 06:41 -0700 |
| Message-ID | <86y299zabl.fsf@linuxsc.com> |
| In reply to | #80807 |
MrSpud_HG@_0b772d8ha3yjo0xb.edu writes: > On Mon, 9 Aug 2021 12:16:46 -0400 > James Kuyper <jameskuyper@alumni.caltech.edu> wrote: > >> On 8/9/21 4:19 AM, MrSpud_ifhov@nldls6_1kg3nl2qnwv.biz wrote: [...] >>> So long as mathematical operations can be done on the pointer >>> types (which is a given or they'd be no use as pointers) then >>> they are de facto integer types and that statement is wrong. >> >> Yes, but when these issues come into play, the relevant >> mathematical operations cannot be done on pointer types. >> The result of a pointer > > They can in *nix which is good enough for me. A few comments... One, in many cases C pointers are represented internally as what are basically integers, but the C standard says pointer types are distinct from integer types, and the rules for operations on pointer types, in particular subtraction of pointer values, are specifed in terms of pointers and arrays and not in terms of integer values. The rules for pointer subtraction depend on the range of the implementation-chosen type ptrdiff_t. Two, the specific values used for things like ptrdiff_t are determined by the particular C implementation being used, not the operating system. The target OS may influence some choices made by the implementation, but it is still the implementation's choice whether to observe those influences. Three, I can tell you from first-hand experience that problems related to the range of ptrdiff_t can and do occur in ordinary C code running on a 32-bit linux system, using gcc to compile.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-06-06 18:48 +0300 |
| Message-ID | <s9iqno$ajd$1@dont-email.me> |
| In reply to | #80161 |
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!
[toc] | [prev] | [next] | [standalone]
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | comp.lang.c++
csiph-web