Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c++ Subject: Re: Is this really necessary Date: Mon, 07 Jun 2021 09:43:57 -0700 Organization: A noiseless patient Spider Lines: 94 Message-ID: <86pmwxd3qq.fsf@linuxsc.com> References: <87r1hevbc8.fsf@nosuchdomain.example.com> <87y2bmphoo.fsf@nosuchdomain.example.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="e6c86ac6dad3f265ee72dc540c206688"; logging-data="31099"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/+t4ULoU5VuFDSV5Xzmqr9uxiHQhRXQwU=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:J8zX1aye3CZtlswZREK9olAJEns= sha1:Mykzbz6CMYoc7JwnWH01xSrQ+Z4= Xref: csiph.com comp.lang.c++:80217 Richard Damon writes: > On 6/6/21 9:49 PM, Keith Thompson wrote: > >> Richard Damon writes: >> >>> On 6/6/21 7:10 PM, Keith Thompson wrote: >>> >>>> Paavo Helde 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++?