- Ping: Keith Thompson and James Kuyper - 1 Update
- Is this really necessary - 5 Updates
- "Nearly a quarter-century later, why is C++ still so popular?" - 3 Updates
| Vir Campestris <vir.campestris@invalid.invalid>: Aug 08 09:52PM +0100 On 07/08/2021 08:19, Bo Persson wrote: >> post on either. > That's because the moderation server got lost years ago, so you just > cannot post anything, even if you want to. Ah. Thanks. Andy |
| MrSpud_85yGi2@1ahbfz.gov: Aug 08 09:18AM On Sat, 07 Aug 2021 12:59:02 -0700 >In C the difference of two pointers might not work, in particular >if the result doesn't fit in ptrdiff_t. I don't know if that >rule is different in C++. Huh? Any type that can be used to hold a pointer address can also be used to hold the difference of 2 pointers. If the difference will be negative then simply invert it. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Aug 08 09:23AM -0400 > On Sat, 07 Aug 2021 12:59:02 -0700 > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >> Richard Damon <Richard@Damon-Family.org> writes: ... > Huh? Any type that can be used to hold a pointer address can also be used > to hold the difference of 2 pointers. If the difference will be negative then > simply invert it. "When two pointers are subtracted, both shall point to elements of the same array object, or one past the last element of the array object; the result is the difference of the subscripts of the two array elements. The size of the result is implementation-defined, and its type (a signed integer type) is ptrdiff_t defined in the <stddef.h> header. If the result is not representable in an object of that type, the behavior is undefined." (C2011 6.5.6p9). If the result of a pointer subtraction were always guaranteed to be representable in ptrdiff_t, then that last sentence would be vacuous. In the C standard, 7.20.1.4p1 describes intptr_t and uintptr_t, and says "These types are optional". A fully conforming implementation may have pointers that are too big to be representable using any supported integer type, and the same is true of pointer differences. |
| Juha Nieminen <nospam@thanks.invalid>: Aug 08 03:04PM > "These types are optional". A fully conforming implementation may have > pointers that are too big to be representable using any supported > integer type, and the same is true of pointer differences. Indeed. For example in x86 16-bit real mode (think MS-DOS) it may well be that a pointer is 32-bit (because it has to contain a segment and an offset) but ptrdiff_t may well be 16-bit, and the compiler may limit eg. arrays to 64 kilobytes (minus 1 byte) so that they will fit inside a segment. A difference between pointers will only give a valid (16-bit) result when they point to the same array (which would be within the same segment). Else you get garbage (if the two pointers are pointing to different segments). |
| Richard Damon <Richard@Damon-Family.org>: Aug 08 01:14PM -0400 On 8/8/21 11:04 AM, Juha Nieminen wrote: > result when they point to the same array (which would be within > the same segment). Else you get garbage (if the two pointers are > pointing to different segments). And a key point is that typically ptrdiff_t will be of the sames size as size_t, only signed instead of unsigned. (This doesn't work if size_t is 16 bits, as ptrdiff_t needs to be at least 17-bits as I remember). This means that if size_t is 32 bits, and ptrdiff_t is also 32 bits, an array of char with size bigger than 0x80000000 can generate differences bigger than can be handled by ptrdiff_t. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Aug 08 08:01PM +0100 On Sun, 8 Aug 2021 09:23:46 -0400 > "These types are optional". A fully conforming implementation may have > pointers that are too big to be representable using any supported > integer type, and the same is true of pointer differences. Note that "array" has a different meaning in C and C++. In C it is (according to C11 §6.2.5/20) "a contiguously allocated nonempty set of objects with a particular member object type, called the element type". Furthermore in C (according to C11 §6.2.6.1/2) "Except for bit-fields, objects are composed of contiguous sequences of one or more bytes, the number, order, and encoding of which are either explicitly specified or implementation-defined". This has been taken to mean that in C the internal bytes comprising an object can themselves be treated as, and iterated over as, an array of char, aided of course by the fact that dereferencing pointers to char pointing to the internals of such objects does not infringe the strict aliasing rule (§6.5/7 of C11). That is, on my reading, no longer true in C++. Although by analogy with C "An object of trivially copyable or standard-layout type shall occupy contiguous bytes of storage" (C++20 §6.7.2/8.4), arrays in C++ have a different definition than in C. As I read C++20 (and I am willing to be corrected), an array is something meeting the requirements of C++20 §9.3.3.4. Accordingly, an array is something declared as an array following the C++ array syntax described there. Merely having a contiguous storage of bytes is not enough (on that reading) for the object concerned to be treated as an array of char in C++. This means that any iteration over a standard layout object using a char pointer type where that object is not actually an array of char, or any pointer arithmetic respecting such char pointer types, results in undefined behaviour by virtue of the restrictions on pointer arithmetic in C++20 §7.6.6/4 and /5. I don't imagine any compilers do anything other than what is hoped for when using pointers to char to iterate over standard layout objects: for one thing, g++ even allows you to carry out pointer arithmetic on void pointers. But it does follow a pattern of C++ turning common and reasonable coding practices, as adopted from C, into apparent undefined behaviour. I would be interested to know if you have different reading. I would be pleased to be wrong. |
| Ian Collins <ian-news@hotmail.com>: Aug 08 01:03PM +1200 On 04/08/2021 01:01, Öö Tiib wrote: > Therefore if we really process 3D triangles directly then it is more convenient > to keep the data layout suitable for rendering API, even if we do part of > processing outside of that API as well. Our application's positioning engine does not render the triangle meshes we use for mapping. Its job is to work out where targets should be on a surface and to generate guidance lines on the map. The rendering is done in using OpenGL on another device. I'm sure this situation isn't uncommon. -- Ian. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Aug 07 10:43PM -0700 On 8/7/2021 6:03 PM, Ian Collins wrote: > surface and to generate guidance lines on the map. The rendering is > done in using OpenGL on another device. > I'm sure this situation isn't uncommon. Not uncommon at all. Not sure if the following scenario is "comparable" or not, however... I have pure C++ that generates scenes for another application to render, PovRay. In this case, I did not implement a raytracer. Imvvho, PovRay is pretty fun to work with. https://youtu.be/skGUAXAx6eg Other times, I will implement a crude distance estimator for 3d work: https://www.shadertoy.com/view/fdBSzm |
| Blue Hat <blue_hat@hackershaven.com.jm>: Aug 08 01:33PM -0500 Lynn McGuire <lynnmcguire5@gmail.com> Wrote in message:r > "Nearly a quarter-century later, why is C++ still so popular?" https://sdtimes.com/softwaredev/nearly-a-quarter-century-later-why-is-c-still-so-popular/"Despite C++?s downward trend on the TIOBE Programming Community index since 2001, the language?s fall from the coveted top two slots in 2020, vociferous and persistent claims that C++ is ?dead like COBOL,? and the inroads the Rust is making in developer circles ? C++ is still as viable, vital and relevant as ever."Because it just works ?And I am not impressed with Rust whatsoever.Lynn Neither am I. -- ----Android NewsGroup Reader---- https://piaohong.s3-us-west-2.amazonaws.com/usenet/index.html |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment