This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [00/10][RFC] Splitting the C and C++ concept of "complete type"
Joseph Myers <joseph@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