On Thu, 18 Oct 2018, Richard Sandiford wrote: > - Type introspection for things like parsing format strings > > It sounded like the type descriptors would be fixed-sized types, > a bit like a C version of std::type_info.
It wasn't clear if people might also want to e.g. extract a list of all members of a structure type from such an object (which of course could either involve variable-sized data, or fixed-size data pointing to arrays, or something else along those lines). > So I didn't see anything there that was really related, or anything that > relied on sizeof being variable (which as I say seems to be a very high > hurdle for C++). The references you gave regarding the removal of one version of VLAs from C++ didn't seem to make clear whether there were supposed to be general issues with variable-size types fitting in the overall C++ object model, or whether the concerns were more specific to things in the particular proposal - but in either case, the SVE proposals would need to be compared to the actual specific concerns. Anyway, the correct model in C++ need not be the same as the correct model in C. For example, for decimal floating point, C++ chose a class-based model whereas C chose _Decimal* keywords (and then there's some compiler magic to use appropriate ABIs for std::decimal types, I think). If you were implementing the SVE API for C++ for non-SVE hardware, you might have a class-based implementation where the class internally contains a pointer to underlying storage and does allocation / deallocation, for example - sizeof would give some fixed small size to the objects with that class type, but e.g. copying them with memcpy would not work correctly (and would be diagnosed with -Wclass-memaccess). Is there something wrong with a model in C++ where these types have some fixed small sizeof (which carries through to sizeof for containing types), but where different ABIs are used for them, and where much the same raw memory operations on them are disallowed as would be disallowed for a class-based implementation? (Whether implemented entirely in the compiler or through some combination of the compiler and class implementations in a header - though with the latter you might still need some new language feature, albeit only for use within the header rather than more generally.) Even if that model doesn't work for some reason, it doesn't mean the only alternatives for C++ are something like VLAs or a new concept of sizeless types for C++ - but I don't have the C++ expertise to judge what other options for interfacing to SVE might fit best into the C++ language. > I think it would look something like this (referring back to > > *Object types are further partitioned into sized and > sizeless; all basic and derived types defined in this standard are > sized, but an implementation may provide additional sizeless types.* > > in the RFC), not really in standardese yet: > > Each implementation-specific sizeless type may have a set of > implementation-specific "configurations". The configuration of > such a type may change in implementation-defined ways at any given > sequence point. > > The configuration of a sizeless structure is a tuple containing the > configuration of each member. Thus the configuration of a sizeless > structure changes if and only if the configuration of one of its > members changes. > > The configuration of an object of sizeless type T is the configuration > of T at the point that the object is created. > > And then borrowing slightly from your 6.7.6.2#6 reference: > > If an object of sizeless type T is accessed when T has a different > configuration from the object, the behavior is undefined. > > Is that the kind of thing you mean? Yes. But I wonder if it would be better to disallow such changing of configurations, so that all code in a program always uses the same configuration as far as the standard is concerned, so that there is indeed a size for a given vector type that's constant throughout the execution of a program (which would be used by calls to sizeof on such types), and so that communicating with a thread using a different configuration is just as much outside the scope of the defined language as processes using different ABIs communicating is today. -- Joseph S. Myers jos...@codesourcery.com
