[cpp-threads] More niggles on the strawman proposal

[Nick Maclaren]

Ben Hutchings <ben at decadentplace.org.uk> wrote:

Thanks for the references, but we are slightly at cross-purposes.

> Structures are copied member-wise by default [class.copy] (12.8/8-9), or
> else by a user-defined copy constructor or copy assignment operator.

Yes.  But the point about threading is that it makes the ORDER in
which simple initialisation/copying occurs visible, whereas that is
not so in purely serial code.

> I was confused by this because there is no C.3.9, but now I see you mean
> C.1.2/5, which refers back to 3.9 in the main part of the standard.  The
> requirement of structure name matching is a syntactic constraint that
> results from overloading; it can be overridden by casting and the
> semantics are defined if the two structures are layout-compatible, just
> as in C.

Sorry.

> I dare say it's more clearly defined, but as for type safety, have you
> read [class.mem] 9.2/14-17 yet?

No, but I knew it had to be there :-)  Yes, that does mean that my
concern about the status of padding bytes does apply to C++ as well
as C.  But, because so many of the OTHER problem wordings are not
present, it is very clear that the dirty tricks that are ambiguously
supported in C are not INTENDED to be supported in C++.  One can
argue about whether the wording DOES permit them, but with C even
the intent is a matter of furious and futile debate.

> It's implicit in references to "standard conversions" and explicit in
> various places.  But I don't see the relevance to the memory model,
> since array-to-pointer shouldn't involve access to the array's storage.

No, it doesn't, but that isn't the problem.  Consider, for example,
memcpy or an implicit array copy.  The question is whether the unit
of specification in the language is the array, each element in an
unspecified order, or each element in index order.  With a purely
serial design, the differences are not visible; with a threaded one,
they are.

> See [expr] 5/8, [dcl.fct] 8.3.5/3, [dcl.init] 8.5/14, [temp.deduct.call]
> 14.8.2.1/2, [temp.deduct.conv] 14.8.2.3/2 (section/paragraph numbers are
> for the current standard; this is possibly not an exhuastive list).

Thanks.  I have found a lot of those, but nothing that would enable me
to decide when I have found a complete list :-(


Regards,
Nick Maclaren.