Joseph Myers <jos...@codesourcery.com> writes: > On Wed, 17 Oct 2018, Richard Sandiford wrote: >> Yeah, can't deny that if you look at it as a general-purpose extension. >> But that's not really what this is supposed to be. It's fairly special >> purpose: there has to be some underlying variable-length/sizeless >> built-in type that you want to provide via a library. >> >> What the extension allows is enough to support the intended use case, >> and it does that with no enforced overhead. > > Part of my point is that there are various *other* possible cases of > non-VLA-variable-size-type people have suggested in WG14 reflector > discussions - so any set of concepts for such types ought to take into > account more than just the SVE use case (even if other use cases need > further concepts added on top of the ones needed for SVE).
[Answered this in the other thread -- sorry, took me a while to go through the full discussion.] >> > Surely, the processor knows the size when it computes using these >> > types, so one could make it available using 'sizeof'. >> >> The argument's similar here: we don't really need sizeof to be available >> for vector use because the library provides easy ways of getting >> vector-length-based constants. Usually what you want to know is >> "how many elements of type X are there?", with bytes just being one >> of the available element sizes. > > But if having sizeof available makes for a more natural language feature > (one where a few places referencing VLAs need to change to reference a > more general class of variable-size types, and a few constraints on VLAs > and variably modified types need to be relaxed to allow what you want with > these types), that may be a case for doing so, even if sizeof won't > generally be used. I agree that might be all that's needed in C. But since C++ doesn't even have VLAs yet (and since something less ambituous than VLAs was rejected) the situation is very different there. I think we'd need a compelling reason to make sizeof variable in C++. The fact that it isn't going to be generally used for SVE anyway would undercut that. > If the processor in fact knows the size, do you actually need to include > it in the object to be able to provide it when sizeof is called? (With > undefined behavior still present if passing the object from a thread with > one value of sizeof for that type to a thread with a different value of > sizeof for that type, of course - the rule on VLA type compatibility would > still need to be extended to apply to sizes of these types, and those they > contain, recursively.) No, if we go the undefined behaviour route, we wouldn't need to store it. This was just to answer Martin's suggestion that we could make sizeof(x) do the right thing for a sizeless object x by storing the size with x. Thanks, Richard