"Uecker, Martin" <martin.uec...@med.uni-goettingen.de> writes:
> Hi Richard,
>
> responding here to a couple of points.
>
> For bignums and for a type-descibing type 'type'
> there were proposals (including from me) to implement
> these as variable-sized types which have some restrictions,
> i.e. they cannot be stored in a struct/union.
But do you mean variable-sized types in the sense that they
are completely self-contained and don't refer to separate storage?
I.e. the moral equivalent of:
1: struct { int size; int contents[size]; };
rather than either:
2: struct { int size; int *contents; };
or:
3: union {
// embedded storage up to N bits (N constant)
// description of separately-allocated storage (for >N bits)
};
? If so, how would that work with the example I gave in the earlier
message:
bignum x = ...;
for (int i = 0; i < var; ++i)
x += x;
Each time the addition result grows beyond the original size of x,
I assume you'd need to allocate a new stack bignum for the new size,
which would result in a series of ever-increasing allocas. Won't that
soon blow the stack?
Option 3 (as for LLVM's APInt) seems far less surprising, and can
be made efficient for a chosen N. What makes it difficult for C
isn't the lack of general variable-length types but the lack of
user-defined contructor, destructor, copy and move operations.
Thanks,
Richard
> Most of the restrictions for these types would be the same
> as proposed for your sizeless types.
>
> Because all these types fall into the same overall class
> of types which do not have a size known at compile
> time, I would suggest to add this concept to the standard
> and then define your vector types as a subclass which
> may have additional restrictions (no sizeof) instead
> of adding a very specific concept which only works for
> your proposal.
>
> Best,
> Martin
>
>
>
>
>
> Am Donnerstag, den 18.10.2018, 13:47 +0100 schrieb Richard Sandiford:
>> 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
