[cpp-threads] Memory model counterproposal: bit-fields

[Boehm, Hans]

I'm concerned here that we are complicating the programming model
for a performance gain which looks marginal to me.  Yes, you can
construct cases in which the new rules result in slower code.
But I don't recall having seen much code for which this would be
an issue.

As far as the programming model is concerned, I think I could
live with Peter's formulation, so long as it's clear that it
doesn't apply to bit-fields of nested structs.  The statement is
certainly simple enough.  But it still seems
to me that it allows significantly more surprising behavior,
for relatively minimal gain.

For example, if I have an interface that uses an
opaque (to the client) struct r to hold a request and its result, where

make_request(r&)

makes the request, and

get_result(r&)

retrieves the result, I can put an r in a struct with a bit field
only if there is no concurrency involved, even though one would
really expect that to be transparent to the client.

Hans

> -----Original Message-----
> From: 
> Cpp-threads_decadentplace.org.uk-bounces at decadentplace.org.uk 
> [mailto:Cpp-threads_decadentplace.org.uk-bounces at decadentplace
> .org.uk] On Behalf Of Peter Dimov
> Sent: Thursday, May 26, 2005 11:54 AM
> To: cpp-threads at decadentplace.org.uk
> Subject: Re: [cpp-threads] Memory model counterproposal: bit-fields
> 
> 
> Nelson, Clark wrote:
> 
> > For this and other reasons, I personally would be satisfied with a 
> > rule that said that any field of a struct object might be 
> written on 
> > assignment to any other field of that object. But I don't 
> imagine I'd 
> > be in the majority in a vote on that proposal.
> 
> "Any member of a struct can be written on assignment to any 
> bitfield member 
> of that struct" seems both sufficient and passable. 
> 
> 
> -- 
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk 
> http://decadentplace.org.uk/mailman/listinfo/cpp-threads_decad
entplace.org.uk