"Uecker, Martin" <martin.uec...@med.uni-goettingen.de> writes: > Am Mittwoch, den 17.10.2018, 13:30 +0100 schrieb Richard Sandiford: >> [ Sorry that there were so many typos in my last reply, will try to >> do better >> this time... ] > > ... >> I think the key difference between sizeless types and full C99-style >> VLAs is that the size and layout of sizeless types never matters for >> semantic analysis. Rather than the sizes of types becoming variable >> (and the offsets of members becoming variable, and constexprs >> becoming >> variable-sized, etc.), we simply don't make those concepts available >> for sizeless types. >> >> So nothing at the language level becomes variable that was constant >> before. >> All that happens is that some things become invalid for sizeless >> types >> that would be valid for sized ones. >>
>> The idea was really for the language to provide a framework for >> implementations to define implementation-specific types with >> implementation-specific rules while disturbing the language itself >> as little as possible. > > I guess this makes it much easier for C++, but also much less useful. 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. The examples with one thread accessing a vector from a different thread aren't interesting in practice; any sharing or caching should happen via normal arrays or malloced memory instead. These corner cases are just something that needs to be addressed once you allow pointers to things. > 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. And of course, making sizeof variable would be a can of worms in C++... (The rejected ARB proposal didn't try to do that.) > If a value of the type is stores in addressable memory (on the stack), > can't we also store the size so that it is available for other threads? But the problem is that once the size becomes a part of the object, it becomes difficult to get rid of it again for the intended use case. E.g. say a vector is passed on the stack due to running out of registers. Does the caller provide both the size and the contents, or just the contents? In the latter case it would be the callee's reponsibility to "fill in" the missing size, but at what point should it compute the size? In the former case, would a callee-copies ABI require the callee to copy the contents with the size given in the argument or the value that the callee would use if it were creating an object from scratch? These aren't insurmountable problems. They just seem like an unnecessary complication when the only reason for doing them is to support sizeof, which isn't something that the use case needs. Also, storing the size with the object would make the size field *become* part of the size of the object, so sizeof (vector) would give you something bigger than the size of the vector itself. It would also open up oddities like: sizeof (x) != sizeof (typeof (x)) being false in some cases. I.e. even if sizeof (x) correctly reported the size that an object x actually has, it isn't necessarily the size that a new object of that type would have, so users would have to be very careful about what they ask. I think both these things would just open the door to more confusion. > Just making it undefined to access a variable with the wong size for the > current thread seems rather fragile to me. In many ways it seems similar to memory management. It's the programmer's responsibility to ensure that they don't access vectors with the "wrong" size in the same way that it's their responsibility not to dereference freed memory or access beyond the amount of memory allocated. And as I mentioned above, noone should be doing that anyway :-) These types shouldn't live longer than a vector loop, with that loop potentially calling functions that are easily identified as "vector functions". Thanks, Richard
