FeedaMail: Comments for Sutter’s Mill

	Comments for Sutter's Mill
	Comment on GotW #91 Solution: Smart Pointer Parameters by earwicker @GregM “which is a problem no matter which kind of pointer” See, Herb made exactly the same kind of observation in his parenthetical caveat: “… but in this respect it's no different than any other aliased object.” What difference does it make to whether we need to take care in this situation? It’s not just a problem for pointers, it’s a problem for any object with mutable internal state, e.g. a string vs. a ‘const string&’ This doesn’t stop it from being a problem in the case of shared_ptr, does it? By accepting a parameter that is a const &, you’ve already introduced at least one alias. You’ve said, in effect, “I don’t care if this object stays alive – I assume all my callers will ensure that for me”. Rather than saying “it’s a guarantee (except it’s not)”, why not instead say we always have the same trade-off to make: 1. copy (slow, but ensures object will survive) 2. ref (fast, doesn’t ensure object will survive) If you follow 2 by default throughout your code, you are practicing the art of “write fast code, then fix it”. If you follow 1 by default, you’re following “write correct code, then optimize it”. Again, choose your poison! Due to the severe performance problem caused by all the ref-counting, optimizing a correct program may be as hard as finding/fixing bugs in a fast program. Read More »
	Delievered to you by Feedamail. Unsubscribe