Quote Originally Posted by Daved View Post
Ok. This part is correct. You have followed the rule with foo3 by ensuring that the original pointer is not destroyed by the original thread until after the new thread is done using it.

You claim that because a switch to foo2 now breaks that rule, that foo2 is dangerous. I'm saying that foo2 is only dangerous because you broke the rule by calling it.

You can break the rule without using foo2. You can use foo2 without breaking the rule. Therefore, the problem is not foo2.
Now here's the thing - perhaps I am doing things the wrong way, but regardless, this happens because I use references in a bad way. And I want to avoid such bugs by safe-guarding it.
I think you'll agree that it's a lot safer when every variable of the memory class is counted towards the ref count. Therefore, I feel it safer ONLY to pass by value then to allow the (potentially) dangerous pass by reference, if used incorrect.

Your example shows that "with your reference counted smart pointer class passing by reference is dangerous and passing by value is not when you are in a threaded environment and when the value is guaranteed not to be corrupted by another thread until immediately after the function call and when the value passed is not used again after the function call."

I'll give you that. That's a lot different than "with your reference counted smart pointer class passing by reference is dangerous".
But that's how data is usually passed between threads. I block the main thread until I'm gauranteed that the functions in the new thread have secured its access to the data. And with shared pointers, this is after the thread has made a local copy of the variable.

Look at this example. Using an int variable in the denominator of a division operation is dangerous:

It doesn't matter how I did it, because the only difference between bar3 and bar2 is the type of the denominator, one uses double, the other uses int. Therefore, the int is at fault, even if I utilized them incorrectly.
I have shown, in this example, however bad my code may look to you, that it's possible to crash the program because a division operation uses an int in its denominator.
Therefore it isn't safe, and I want to ban it.

Hopefully you see the parallels to your example. The rule is don't divide by zero. You can break the rule without making the denominator an int. You can make the denominator an int and not break the rule. Therefore, the problem is not the fact that the denominator is an int.
The thing here is that if I can avoid such bugs by banning such practice in some ways that do not ban needed functionality, I don't see why I shouldn't. Like adding "const" to varaibles that aren't supposed to be modified, by safe-guarding or banning some practices, I can find more bugs at design time.

>> Now then, why don't you show me an example of how YOU think the code should look like?
I would use iMalc's suggestion. Force a copy to be made so that the thread cannot possibly use the original pointer unless the reference count has been incremented.
That's only done through pass by value.