- Can similar programs be legel, warning or error? - 2 Updates
- Does std::regex need to be so large? - 1 Update
| James Kuyper <jameskuyper@alumni.caltech.edu>: Aug 24 05:35PM -0400 On 8/24/20 4:02 PM, Chris Vine wrote: > undefined behaviour in C++, although it is supported by gcc and clang. > You can only legally access the currently active member of the union in > C++ (it is different in C). In C90, "if a member of a union object is accessed after a value has been stored in a different member of the object, the behavior is implementation-defined.". It was pretty much universally the case that implementations defined the behavior to be that "the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type" (C2011 footnote 97). People wrote code that depended on that fact. This clause was dropped in C99. Many people claim that, as a result of what the C99 standard said elsewhere about the representation of objects, the behavior described above became mandatory. Personally, I don't see how that conclusion can be derived from the words of the C99 standard. In C2011, the C committee added the non-normative footnote 97 cited above to confirm that this is the correct interpretation of the normative words of the standard, without making any corresponding change to the normative words. Under the circumstances, I'm willing to rely upon footnote 97, despite not seeing how it's validity can be derived from the normative words. Given that history, I'm comfortable about making the same assumption in C++ code, despite the fact that the wording of the C++ standard is still closer to what C90 said than to what C2011 says. > Using reinterpret_cast is far worse (if that is what the OP has > been trying to do) because that is not supported by either gcc or clang > without the no-strict-aliasing flag. ... I wasn't recommending this approach in an absolute sense, only as an improvement over the reinterpret_cast<> approach he was using. > ... A standard conforming approach is > to use std::memcpy, which is also as efficient as a union in practice > because it is a compiler built-in. Given long l = 123456789; int i; std::memcpy(&i, &l, sizeof i); does the C++ standard guarantee anything more about the value stored in 'i' than it does about the corresponding union code? If so, where? |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Aug 24 05:56PM -0400 On 8/24/20 4:48 PM, Vir Campestris wrote: > James, I admit I don't expect to find one anytime soon - but if your > compiler chooses to align uint32_t on 64-bit boundaries that's not going > to behave - specifically the copy constructor. No padding is allowed between consecutive elements in an array. This implies that the size of a type includes all of the space between consecutive elements of an array of that type, even if it doesn't actually use all of that space. The exact-sized types such as uint32_t are prohibited from having padding bits (that prohibition is in the C standard, cross-referenced from the C++ standard). Therefore, a conforming implementation of C++ is not allowed to use such a type for uint32_t. |
| Vir Campestris <vir.campestris@invalid.invalid>: Aug 24 09:53PM +0100 On 22/08/2020 09:42, Bonita Montero wrote: >> down the program because it fills the code cache with irrelevant stuff! > That's actually not relevant because i-caches are large enough to hold > the hot-spots. Well the guys at Microsoft told me that they compile with optimisation for size. Because "A page fault can ruin your day". I've got 32Gb on my dev machine, and 16 on this thing. If the code is bigger I'll have less free to use as disc cache. Given that our compiled code base is 144G I'm not going to fit it all into RAM any time soon. Andy |
| 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