On Nov 11, 2007, at 12:32 AM, Neil Booth wrote: > Chris Lattner wrote:- > >> Yep, I think this is a very reasonable way to go. QualType itself is >> just an optimization for representing types. Instead of having >> Type*'s everywhere, and having a "ConstType" type and "RestrictType" >> type (that wrapped some other type), the information is encoded into >> QualType. >> >> However, this optimization for CVR qualifiers doesn't impact other >> "qualifiers". It would be very reasonable to have an >> AddressSpaceQualifiedType class, which takes an address space ID >> and a >> QualType. This combines the space/time efficiency niceties of >> QualType with the generality of having explicit classes for all of >> these. > > Having qualifiers in multiple places will make "qualifier calculus" > like > > o is A unqualified? > o does A have all the qualifiers of B? >> > etc., awkward, no?
Nope, it is very simple. CVR qualifiers *only* exist on QualType. This means that for something like: "const volatile randomqual int" The node for "randomqual" would contain *just* a "Type*" (not a qualtype) to int. The reference to "const volatile randomqual int" would be a qualtype whose Type* points to the above node, but has the "CV" bits set. This means you can have exact type equality checks in constant time with qualtype comparison still. > o what is the unqualified form of A? > This does require an extra check, but that should be hidden in QualType itself. -Chris _______________________________________________ cfe-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
