[cpp-threads] RE: volatile, memory models, threads

[Nick Maclaren]

"Nelson, Clark" <clark.nelson at intel.com> wrote:
>
> I want to be sure I understand you. You seem to be saying that all the
> other places in the standard which *seem* to promise that a cv-qualified
> type must have the same size as an unqualified type can be interpreted
> not to do so, and that the only provision of the standard which actually
> requires that they have the same size is the promise about adding
> qualifiers in a pointer conversion.

More-or-less, yes, but I think that your wording is biassed.

I don't guarantee to have found every section with such wording
(searching PDF is a major pain), but I am pretty sure that there
are far fewer sections that even "seem" to make such a promise
than is being claimed.  I would be a lot happier if people who
claim that there are such sections were to point out a few.

When this was last investigated in a C context, we found nothing
significant, and this aspect of C++ is closely modelled on C.

> If that were true, the next question would be: so what? The net result
> is still that cv-qualified and unqualified types must have the same
> size. You could propose to change that, and point out all the loopholes
> in the other paragraphs in the standard. I suspect that the result would
> be a lot of editorial clarifications; that the committee would ratify
> the "common assumptions" about what it already intends to say.

That is a good argument for not changing anything for the existing
cv-qualifiers (not even for volatile).  It is, however, a very poor
argument against adding a new cv-qualifier that could not be added
to an existing type.  My belief (and assertion) is that the standard
is ALREADY fully consistent with a cv-qualified type being a different
size from its base type if that ONE aspect is not permitted for the
new qualifier.

Look, this was debated AT LENGTH in a C context in the late 1980s,
and again in the 1990s, and the consensus was that the (C) standard
did NOT require them to be the same size but that anything else was
effectively unimplementable BECAUSE you could add cv-qualifiers.

Don't blame ME for that one - I argued that that position was
insanity.

> Oh, and concerning chapter and verse: have you considered 3.10p15, which
> allows access to an object through a cv-qualified lvalue referring to
> it?

Of course.  Why do you think that I hadn't?

That is the main section that states that cv-qualifiers can be added
but not lost.  My belief is that the only change needed to that
section would be to state that it applies to const and volatile, but
not to atomic.  End of change to 3.10p15.

I believe that there are about half a dozen places where the current
wording would have to exclude atomic from being added, but it might
be fewer than that (possibly only two).  That would need tracking
down if that approach were favoured.

I really AM serious that the standard is like that.  If you know of
any clear statements in the standard EXCEPT THE ONES THAT ALLOW THE
ADDITION OF CV-QUALIFIERS, then please do tell.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679