FeedaMail: Comments for Sutter’s Mill

	Comments for Sutter's Mill
	Comment on GotW #90 Solution: Factories by Leo Tiny typo: “by calling members functions on it” Read More » Comment on GotW #89 Solution: Smart Pointers by Herb Sutter @nosenseetal: No, you can’t use a unique_ptr or a shared_ptr that way. A given shared_ptr object is like any other normal object — if you have multiple concurrent accesses and one is a writer (non-const) you have to protect it using a mutex or other synchronization. What synchronization shared_ptr does internally is to protect the reference counts when they are read/written via *different* shared_ptr objects, because the caller can’t possibly know which shared_ptrs share state and figure out the right external synchronization, nor should he. The same issue arises when two strings share implementations because of refcounted copy-on-write, or with the polygon::area discussed in GotW #6b. Read More » Comment on GotW #90 Solution: Factories by Herb Sutter @Leo: Thanks, fixed. Read More » Comment on GotW #90 Solution: Factories by Motti Lanzkron This article raises two questions in my mind. 1. Does the fact that we now have explicit cast operators mean that we no longer need the “safe bool idiom”? 2. Perhaps the standard should include a self documenting unowned_ptr template for cases where you semantically *want* to return a raw pointer. Read More » Comment on GotW #90 Solution: Factories by Herb Sutter @Motti: 1. Yes. 2. What benefit is there to providing another name for * pointers? FWIW we do now teach not to use owning * pointers, but non-owning * pointers are fine — see the GotW #91 solution that will be posted tomorrow for an example. Read More »
	Delievered to you by Feedamail. Unsubscribe