This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C/C++ PATCH to add __typeof_noqual (PR c/65455, c/39985)

On 06/28/2017 03:19 AM, Joseph Myers wrote:
On Wed, 28 Jun 2017, Martin Sebor wrote:

I.e., just having blocks to remove qualifiers of kind X is not sufficient
without "remove all qualifiers (possibly except these kinds)" as well.  I
suppose you could have __remove_quals (const volatile _Atomic, expr) and
__remove_quals_except (_Atomic, expr) or similar (with some keyword that
goes in there to mean "any address space").

Right.  My point isn't that the bigger features shouldn't exist,
but that they can and should be built on top of the primitives
and defined not in the compiler but in a header.  With
__bultin_remove_const() and __builtin_remove_volatile()
a __typeof_noqual(x) can be a macro that expands to these two,
plus any others as/if necessary, with any other additional

My point is that users should not need to update their definitions every
time another qualifier is invented.  Either you need the "remove
qualifiers except" functionality in the language, or you need a
*compiler-provided* header

Yes, that's what I'm suggesting.  It could also be a macro defined
by the driver on the command line, to avoid having to #include
a header.   But providing it as a built-in, like the lower-level
primitives, as a convenience wrapper around them, would be fine

that defines "remove qualifiers except"
operations for every combination of qualifiers in that version of the
compiler (because "remove qualifiers except _Atomic" and "remove
qualifiers except address spaces" cannot be composed into "remove
qualifiers except _Atomic and address spaces, and "remove const, volatile,
restrict and address spaces" is not something user code should need to
hardcode when the intent is "remove qualifiers except _Atomic").

I'm not sure I understand what you're trying to say.  I thought
we agreed earlier that __typeof_noqual__ would remove all type

If you are saying that there are qualifiers that may need to be
removed for some use cases but kept for others (I mentioned one:
removing one or the other qualifier from const _Atomic T*, but
not both) then that's exactly why I argue for providing lower-
level primitives targeted at each of the qualifiers separately.
Having __typeof_noqual__ remove some but not all qualifiers would
be surprising to say the least.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]