Re: Member variables dependency policy

For my 2 cents, I prefer the second option, as it helps document the
intent of who ever wrote the code - in other words it's self
documenting.  Also bugs arising from option 1 and a user overlooking the
detail would quite hard to track down.  Especially if you are the one
that did the overlooking! ;-)

Nigel 

On Wed, 2010-03-24 at 14:09 +0100, Daniel Wallin wrote:
> 1. Change the default behaviour so that pointer members doesn't
>    imply a dependency.
> 
> 2. Add a dummy policy, similar to "yield", that can be used to suppress
>    the dependency:
> 
>      def_readwrite(&B::a, no_dependency)
> 
> I'm leaning toward (2) because it's generally more safe to assume
> ownership. Doing (1) might mean we end up with a lot of code that SHOULD
> use dependency() but doesn't because the user overlooked the detail.
> Also, (1) breaks backward compatibility, but I'm willing to do that if
> it's a better design.
> 
> What do you think?
> 



------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev