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

[Herb Sutter]

I think folks are talking past each other a little here, due to an
unnecessary analogy. :-)

Nick, your main point seems to be about creating "atomic" as a new
cv-qualifier and allowing "atomic T" and "T" to have different layouts.
I think that's a fine proposal to discuss. (Also, did you consider
atomic<T> as a specializable template library type?)

What's confusing the issue, and what seems to be a needless red herring,
is the academic argument that the C and C++ standards might happen to
almost allow "cv T" and "T" to have different layouts today. Whether or
not that's true, it's irrelevant:

  - it's irrelevant to "atomic" (we can consider that rule for "atomic"
on its own merits)

  - it's irrelevant to the standard (which has to allow const-qualified
objects to be passed to legacy const-incorrect functions, so the layouts
had better be the same)

  - it's irrelevant to existing practice (I doubt I'm exaggerating when
I presume that billions of lines of existing code assume this, and
there's no way the committee or the vendors can afford to break that
code)

So although allowing "cv T" and "T" to have different layouts is
probably a non-starter, it could well be a wonderful idea to allow
"atomic T" and "T" to have different layouts and this merits discussion.
I don't think you need to argue for that by analogy to const/volatile --
that just confuses the issue.

Does that make sense?

Herb


> -----Original Message-----
> From: cpp-threads-bounces at decadentplace.org.uk [mailto:cpp-threads-
> bounces at decadentplace.org.uk] On Behalf Of Nick Maclaren
> Sent: Wednesday, March 01, 2006 9:16 AM
> To: C++ threads standardisation
> Subject: RE: [cpp-threads] RE: volatile, memory models, threads
> 
> "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
> 
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads