Hi Joseph, Joseph Myers <[email protected]> writes:
> Do you have a sense of how the design would be adapted if in future it
> needs to handle an arbitrary set of qualifiers determined when the
> compiler runs (so objects that can store qualifier sets need to
> involve dynamic allocation in some cases)? For example, for features
> such as the N3587 "strong typedefs" proposal.
Hm, I think qualifier_set should ease implementing N3587, if the C FE
was to be also converted to use the operations provided by qualifier_set
(join, merge, etc) rather than performing the same work inline.
I see that at least one more operation would have to be introduced, that
strips non-virtual qualifiers ("Unlike a concrete qualifier, the virtual
qualification is not removed by value conversion, and may appear at any
level of derivation."), so, an operation like 'value_convert'.
'merge' would have to be adjusted to respect the hierarchy of these
virtual qualifiers ("The composite type of two different strongly-typed
typedef names inherits the strong typing associated with both names." -
this is the operation 'merge' implements, you'll notice it does the same
for address spaces), as would 'can_qualify' and 'join'.
None of this should require us to go back and replace qualifier_set
itself, however. It would just require us to complicate its operations.
Taking the setup from example 6:
[[strong]] typedef int S1;
[[strong]] typedef int S2; // unrelated to each other
S1 s1 = ...;
S2 s2 = ...;
... it seems to me that the following holds:
[[strong]] typedef typeof (s1 + s2) S3;
S3 s3_1 = s1; // OK
S3 s3_2 = s2; // OK
S1 back_1 = s3_1; // not OK
S2 back_2 = s3_2; // not OK
... and that S3 has as its "super"qualifiers those generated S1 and S2.
This seems to imply to me that these virtual qualifiers form a DAG.
So, we'd need a new (presumably garbage collected) type (say,
'strong_qualifier') that contains a set of its parents (from which
implicit conversion is possible), and which represents one such instance
of [[strong]]. If we lean into the GC here, we can use the pointers to
test for equivalence (two [[strong]] typedefs of the same type would
generate two new instances of strong_qualifier which are distinct by
pointer even if they have the same set of parents, which is what we
want; though we probably also ought to hold the location of the typedef
name that created that virtual qualifier for diagnostic purposes).
A qualifier_set then holds a set of such garbage collected types (to
distinguish 'typedef typeof (s1 + s2) S4' from the 'S3' given above; S4
would have virt. qualifiers of S1 and S2, and S3 would have a new,
singular virt. qualifier whose parents are S1 and S2).
> (I think that particular proposal is seriously flawed in both the
> design and the specification, including the whole idea of expressing
> things in terms of qualifiers rather than some other concept, but I
> still think it's worth considering how the available qualifiers being
> added to during a translation unit could be handled. Certainly I hope
> that typed qualifiers are a step in the right direction for anything
> requiring such dynamic allocation in future.)
Indeed, I'm also not really convinced by it either, but it seems
implementable.
--
Arsen Arsenović
signature.asc
Description: PGP signature
