- Observable end padding in arrays - 9 Updates
- who's at fault, me or compiler? - 5 Updates
- Fixing some undefined behavior - 8 Updates
- More questions about operator overloading - 3 Updates
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Jul 06 06:26AM -0700 > recently about why there is no multidimensional version of std::array. > Why should there be? Because, AFAIK, std::array<std::array<T, X>, Y> is not > guaranteed to be contiguous. Surely the intention is that sizeof (std::array<T,N>) == sizeof (T[N]) (that is, there is no padding, and both are equal to N * sizeof (T)). If the text of the Standard doesn't convey that clearly then the property might deserve being addressed explicitly, but is there any question that the intention is for std::array<T,N> to be just the elements and nothing else (and in particular, no padding)? |
| "Öö Tiib" <ootiib@hot.ee>: Jul 06 08:47AM -0700 On Monday, 6 July 2020 16:26:59 UTC+3, Tim Rentsch wrote: > property might deserve being addressed explicitly, but is there any > question that the intention is for std::array<T,N> to be just the > elements and nothing else (and in particular, no padding)? I can't find anything in standard that forbids compiler to add something after the array in the aggregate struct (that std::array is). My skills to guess intentions of other people have been always worse than my searching skills ... so I would indeed like that intention (if it exists) to be expressed bit more obviously. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Jul 06 08:48AM -0700 On Monday, July 6, 2020 at 9:26:59 AM UTC-4, Tim Rentsch wrote: > property might deserve being addressed explicitly, but is there any > question that the intention is for std::array<T,N> to be just the > elements and nothing else (and in particular, no padding)? As usual, I'm more concerned about what the committee actually wrote, not what it intended to write (though the intent should certainly be taken into consideration when determining how any failure to correctly convey the intent should be corrected). The relevant words for std::array are: "An array is a contiguous container (26.2.1)." (26.3.7.1p1) "A contiguous container is a container that supports random access iterators (27.2.7) and whose member types iterator and const_iterator are contiguous iterators (27.2.1)." (27.2.1p13) "Iterators that further satisfy the requirement that, for integral values n and dereferenceable iterator values a and (a + n), *(a + n) is equivalent to *(addressof(*a) + n), are called contiguous iterators." (27.2.1p6) That text rules out padding between elements, but does not prohibit a std::array<T> object from containing other things in addition to the individual elements of the array, either before or after the elements, possibly including padding. Unlike you, I see no reason to assume that the failure to address such possibilities was unintentional. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 06 08:44PM +0200 On 06.07.2020 15:26, Tim Rentsch wrote: > property might deserve being addressed explicitly, but is there any > question that the intention is for std::array<T,N> to be just the > elements and nothing else (and in particular, no padding)? The original Boost implementation was a simple `struct`, an aggregate, to support C++03 curly braces initialization. That didn't formally prevent compilers from adding padding, but modern compilers do not add padding needlessly. As I recall the question of whether `struct{ char x; }` is practically guaranteed to be of size 1 has been discussed many times (though perhaps not in this group), and the answer has always been yes, with current compilers. However it's not formally guaranteed. And with the committee's focus on standardizing new features instead of established practice, I guess there will never be a standard `#pragma pack`, or equivalent attribute which would be more ideal, perhaps. - Alf |
| Juha Nieminen <nospam@thanks.invalid>: Jul 06 09:32PM >> Why should there be? Because, AFAIK, std::array<std::array<T, X>, Y> is not >> guaranteed to be contiguous. > Why? If you have something like struct S { char data[5]; }; is something like S table[100]; guaranteed to be exactly 500 bytes in size? |
| Juha Nieminen <nospam@thanks.invalid>: Jul 06 09:35PM > individual elements of the array, either before or after the elements, > possibly including padding. Unlike you, I see no reason to assume that > the failure to address such possibilities was unintentional. The problem I see is not that there would be padding between array elements, but that there may well be padding at the end of a struct. In other words, if you have like struct S { char data[5]; } S table[100]; is 'table' guaranteed to be 500 bytes in size? Is it guaranteed that there will be no padding at the end of that struct? (I genuinely don't know.) |
| red floyd <no.spam@its.invalid>: Jul 06 03:01PM -0700 On 7/6/20 2:32 PM, Juha Nieminen wrote: > is something like > S table[100]; > guaranteed to be exactly 500 bytes in size? No, because S itself is not guaranteed to be exactly 5 bytes. However, table is guaranteed to be 100 * sizeof(S) |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jul 06 03:16PM -0700 On 6/29/2020 2:38 PM, Chris Vine wrote: > contiguity and localization and so encourage vectorized instructions. > Much as I appreciate garbage collection, this is the kind of low level > stuff where C and C++ and their array syntax come out well. Agreed. One can represent n-ary arrays in a 1d array. Humm... Is the placement new array form basically useless because the program does not know the one "true" size? If the implementation adds in any extra meta data, such as how many dtors to call when the array form of delete is used, then the size of the user provided buffer will not be sufficient? |
| Paavo Helde <eesnimi@osa.pri.ee>: Jul 07 01:33AM +0300 07.07.2020 00:35 Juha Nieminen kirjutas: > S table[100]; > is 'table' guaranteed to be 500 bytes in size? Is it guaranteed > that there will be no padding at the end of that struct? No, of course not. An implementation can easily decide that such a struct is most effectively accessed when aligned on a 8-byte border, for example. In this case sizeof(S) would be 8. I guess the same applies for nested std::arrays. If you want a contiguous array with linear indexing, allocate a single continuous array; if you want multidimensional indexing, allocate a nested multidimensional array. It's as simple as that. |
| boltar@nowhere.co.uk: Jul 06 07:00PM On Fri, 3 Jul 2020 19:22:59 +0000 (UTC) >> I can lend you a nice spade to help you dig that hole even deeper if you >like. >I just love your projection there. It's quite clear that this isn't Thank you. Welcome back, took you long enough to think up a riposte. Shame it wasn't worth the effort. |
| boltar@nowhere.co.uk: Jul 06 07:02PM On Fri, 3 Jul 2020 19:26:32 +0000 (UTC) >I noticed earlier that you didn't answer my question. Is this >instantiating a class or not? >static const MyClass obj; Yes. And obj doesn't exist until the binary is loaded and the instatiation code is run. Whats your point? MyClass exists in the binary, obj does not. |
| Juha Nieminen <nospam@thanks.invalid>: Jul 06 09:27PM >>I just love your projection there. It's quite clear that this isn't > Thank you. Welcome back, took you long enough to think up a riposte. Shame > it wasn't worth the effort. While I'm certain you only read like first two or three lines of my post and skipped the rest and hurried to post something just to have the final word, I still think that you may yet grow up and learn in the next 10 to 20 years. You may not want to believe it right now, but it may well happen. Meanwhile, just a word of advice: Just give up, for your own sake. Stop digging the hole deeper. You are not going to "win" anything. Just stop. |
| Juha Nieminen <nospam@thanks.invalid>: Jul 06 09:30PM >>static const MyClass obj; > Yes. And obj doesn't exist until the binary is loaded and the instatiation > code is run. Whats your point? MyClass exists in the binary, obj does not. The compiler may well make that into a data in the text section of the binary (because it's const), depending on how exactly that class is implemented. Meaning it won't create the object at runtime, but it will be data in the executable binary itself. Or if it's implemented in another manner, it may well create code that initializes it at runtime (and eg. does memory allocations or whatever). So, is it instantiated in both cases or not? |
| Paavo Helde <eesnimi@osa.pri.ee>: Jul 07 01:20AM +0300 >> static const MyClass obj; > Yes. And obj doesn't exist until the binary is loaded and the instatiation > code is run. Whats your point? MyClass exists in the binary, obj does not. MyClass definitely does not exist in the binary. Classes are compile-time concept and are not present in the generated binary, in C++. There is no data structure in the generated binary representing the class. At most you will have a typeid tag for RTTI, but this is just a simple identification tag. There are proposals to add reflection to C++ which would mean a bit more presence of classes in binary, but AFAIK these have not yet materialized. I agree with you that the object does not exist before the binary is loaded, as before loading it does not have an address in the program memory space. |
| "Öö Tiib" <ootiib@hot.ee>: Jul 06 05:19AM -0700 > req = &*pendingRequests.emplace_back(::new cmwRequest); > frntBuf.getPacket((::sockaddr*)&req->frnt, &req->frntLn); > gotAddr = true; Either ... req->~cmwRequest(); ... is missing from here or the next line is misplaced. > to pass the "frnt" and "frntLn" fields to the constructor > I use with placement new. And then use them to initialize > the fields. Thanks in advance. Unsure what you do there and ask here. Better write short fully compileable and runnable program that illustrates your problem. |
| woodbrian77@gmail.com: Jul 06 07:29AM -0700 On Monday, July 6, 2020 at 7:20:03 AM UTC-5, Öö Tiib wrote: > req->~cmwRequest(); > ... is missing from here or the next line is misplaced. > > ::new (req) cmwRequest(frntBuf); I guess it's missing. > Unsure what you do there and ask here. Better write short > fully compileable and runnable program that illustrates your > problem. My explanation wasn't the greatest. It's related to this: https://stackoverflow.com/questions/14659752/placement-new-and-uninitialized-pod-members Brian |
| "Öö Tiib" <ootiib@hot.ee>: Jul 06 08:15AM -0700 > > problem. > My explanation wasn't the greatest. It's related to this: > https://stackoverflow.com/questions/14659752/placement-new-and-uninitialized-pod-members If you need your cmwRequest object to be built in multiple steps then implement such steps, perhaps even add a debug member that indicates and allows to check its ripeness in debug builds. Do not try to cheat pointlessly with confusing and illegal tricks. Otherwise anyone can build your library with some ub-sanitiser, get a crash, look at code and publish major "ewwww" about it. |
| woodbrian77@gmail.com: Jul 06 11:40AM -0700 On Monday, July 6, 2020 at 10:15:52 AM UTC-5, Öö Tiib wrote: > not try to cheat pointlessly with confusing and illegal tricks. > Otherwise anyone can build your library with some ub-sanitiser, > get a crash, look at code and publish major "ewwww" about it. This is a problem with an application, not my library. By the grace of G-d, my software is good, but it's not perfect. Brian |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jul 06 10:18PM +0100 > This is a problem with an application, not my library. > By the grace of G-d, my software is good, but it's > not perfect. Your fucking god doesn't fucking exist. And yes, I will fucking swear here. /Flibble -- "Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| woodbrian77@gmail.com: Jul 06 02:26PM -0700 On Monday, July 6, 2020 at 4:18:14 PM UTC-5, Mr Flibble wrote: Don't swear here, please. Brian |
| "Öö Tiib" <ootiib@hot.ee>: Jul 06 03:02PM -0700 > > Otherwise anyone can build your library with some ub-sanitiser, > > get a crash, look at code and publish major "ewwww" about it. > This is a problem with an application, not my library. I do not really know precise architecture of your software, what is application, what is library what is may be just some helper tool, sorry. The "cmwRequest" did sound like something that can be neccessary part of your serialisation system. People who decide things in business often understand far less than me. > By the grace of G-d, my software is good, but it's > not perfect. Oh "perfect" is impossible. It is usually said about something that is significantly more expensive and insignificantly better than "good". Avoiding undefined behaviors in portable code however is necessary to achieve "not bad" level. |
| red floyd <no.spam@its.invalid>: Jul 06 03:03PM -0700 > On Monday, July 6, 2020 at 4:18:14 PM UTC-5, Mr Flibble wrote: > Don't swear here, please. > Brian Fuck off trying to impose your view of morality on everyone else. |
| Juha Nieminen <nospam@thanks.invalid>: Jul 06 06:15AM > T operator +(double arg1, T arg2); > That handles 2.9+t. > Is that really necessary? Isn't addition commutative? The problem isn't if it's commutative or not. The problem is that if the operands are of different types, whether you want to support specifying them in either order. If you want to support things like: MyClass obj1, obj2; obj1 = obj2 + 10; obj1 = 10 + obj2; obj1 = obj2 - 10; obj1 = 10 - obj2; there are four overloads there that need to be written (especially if you don't want an integer to implicitly convert to an object of type MyClass). I remember years ago where I was in a situation where I needed a function to take three parameters. Any of the three parameters could be one of two types (which weren't implicitly convertible between each other). That's like an exponential number of overloads. I don't think there's a perfect solution for this. You could just template all the parameters (or, in modern C++, make them auto), but making a function templated can be highly problematic (as the implementation now needs to be available where the function is called) and the types being completely free can also cause problems and, at a very minimum, obscure error messages if they are of the wrong type (although I think C++20 gives tools to make this much better). You could also create some kind of "proxy" type that contains some kind of reference to the original values, but that can be problematic too. Also probably adds a level of inefficiency. |
| Ike Naar <ike@otaku.sdf.org>: Jul 06 07:41AM > Could it ever be that > A != B and !(A == B) > differ? It can happen if A and B have class type for which operator== and operator!= are user-defined in an inconsistent way. Another caveat: if A and B have floatingpoint type and can be NaN. e.g. if x is NaN, x==x yields false and x!=x yields true. Though A!=B and !(A==B) will still be equivalent, other relational operators might give surprising results, e.g. A<=B might differ from !(A>B) . |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Jul 06 11:30AM +0100 > Though A!=B and !(A==B) will still be equivalent, > other relational operators might give surprising results, > e.g. A<=B might differ from !(A>B) . True. But it would be reasonable for a language to generate defaults for all of the missing relational operators, defaults that could be overridden by explicit user definitions. Similarly, by declaring a function to be commutative in at least two of its arguments, the implementation could generate default implementations from just one implementation of each type pair (or group). -- Ben. |
| 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