- Observable end padding in arrays - 3 Updates
- who's at fault, me or compiler? - 2 Updates
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jul 07 12:07PM -0700 On 7/6/2020 11:26 PM, Juha Nieminen wrote: >> multidimensional array. It's as simple as that. > Hence why we need a multidimensional version of std::array, because > std::array<std::array<T, X>, Y> is not guaranteed to be contiguous. Humm... I would not mind a multidimensional version of std::array. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Jul 07 03:29PM -0400 On 7/7/20 10:30 AM, Manfred wrote: > Not really, for example the following definition about structure type > does not mention padding either, but we know that padding may very well > exist there. Yes, we know it because it's explicitly specified that "There may be unnamed padding within a structure object, but not at its beginning." (6.7.2.1p15) and "There may be unnamed padding at the end of a structure or union." (6.7.2.1p17). There are no such statements for arrays. The existence of an exception implies the existence of a rule that it is an exception to. The fact that there need to be explicit statements that padding is permitted between the members of a struct and at the end implies that such padding is not permitted for arrays, for which no such exceptions have been specified. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 08 01:03AM +0200 On 07.07.2020 08:37, Keith Thompson wrote: > understand it it provides its own descriptions of everything in the core > language. I'm not aware of anything in the C++ core language that's > defined by the C standard. Minimum ranges of integer types. > that the C core language definition fills in the gaps. > It's not 100% clear to me that either the C or C++ discussion of array > types completely excludes the possibility of padding at the end. For the C++ standard it's explicitly stated in normative text, but implicitly referring to some other unspecified text via "this implies". It was the same with the UB of dereferencing a nullpointer, a reference to other text that was nowhere to be found. On the contrary, the only text that clearly was about that, was a statement that it was /not/ UB in a `typeid` expression. I believe there was an attempt to fix this in C++11 but as I recall they didn't manage to clear it up completely, although that would not be hard to do -- which IMHO on its own brings the competence of the committee into question. Then later we got UTF-8 character literals and `std::byte` and the C++20 sabotage of UTF-8 from `std::filesystem::path` and silly support of compiler internals like optimization of successive `new`-expressions, and such, not to mention continuations misleadingly called coroutines and without the necessary library support for the very Microsoftic base functionality. It's scary. - Alf |
| Manfred <noname@add.invalid>: Jul 07 08:38PM +0200 > The class memory layout has to be stored in some form somewhere in the binary > otherwise on the fly objects could never be created. Yes, they can. It is called construction. |
| Paavo Helde <eesnimi@osa.pri.ee>: Jul 08 12:16AM +0300 >> C++. There is no data structure in the generated binary representing the > The class memory layout has to be stored in some form somewhere in the binary > otherwise on the fly objects could never be created. Right, that's why it is not possible in C++ to construct classes at run time and to create objects from them "on the fly". The compiled code accesses object members at fixed offsets which are hardcoded in the code and not looked up anywhere at run time. Of course one can implement in C++ a new (scripting) language which does exactly such things as dynamic class building, but those would then be classes and objects of that new language, not of C++. |
| 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