[cpp-threads] More niggles on the strawman proposal

[Ben Hutchings]

On Thu, 2006-01-19 at 11:09 +0000, Nick Maclaren wrote:
> Ben Hutchings <ben at decadentplace.org.uk> wrote:
> >
> > > Upon studying it, C++ seems to have eliminated (or not introduced) all
> > > of the worst problems.  My reading of C++ is that basic actions take
> > > place on most derived types,
> > 
> > What do you mean by "basic actions"?
> 
> The actions that are the concern of the memory model - i.e. the units of
> 'overlapping'.  For example, initialising an integer array is made up of
> the basic actions of initialising each element, but (simple) copying of
> a structure is a basic action.

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.

<snip>
> > C++ has stricter rules for non-POD types, but for POD
> > types I'm not aware of any restrictions on type-punning beyond those in
> > C.  There's actually a slight relaxation in that an object of POD type
> > may also be accessed as an array of char or unsigned char, where C
> > doesn't promise this for an array of char.
> 
> Absolutely not.  It is an order of magnitude tighter.  Bjarne deliberately
> excluded some of the less safe features of C - see C.3.9 for one - but
> most of them are not actually mentioned in Annex C.

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.

> See also 1.8, 3.9 and 3.10 para. 15 for something that is a LOT
> tighter than C.

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

> > > There are only three issues that I can't resolve.
> > > 
> > > The first is that I can't find where it specifies when the array to
> > > pointer conversion is performed, and when it is not.
> > 
> > It is done wherever an rvalue is required.
> 
> Yes, but where is that specified?  It makes an important difference, in
> that it could affect the overlap rules for array-valued built-in
> library functions.

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.

> > The conversion itself is specified as a standard conversion in
> > [conv.array] (4.2).  There are references in several places to
> > lvalue-to-rvalue conversion, array-to-pointer conversion and
> > function-to-pointer conversion, the latter two covering the types that
> > don't have rvalues.
> 
> Yes, but I haven't found anything that says WHERE it is done :-(

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).

<snip>
> > >     1) C++ makes a definition visible before it is initialised (3.3.1)
> > > and forbids access to its members only for const-qualified objects
> > > (8.5).  In fact, there is an implication that constructors with
> > > side-effects are called sequentially in sub-object order.
> > 
> > That's guaranteed by [class.base.init] (12.6.2).
> 
> I can't find that.  Can you give a paragraph number?
<snip>

Sorry, that's paragraph 5.

Ben.

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://www.decadentplace.org.uk/pipermail/cpp-threads/attachments/20060119/ff7f810f/attachment.pgp