FeedaMail: Comments for Sutter’s Mill

	Comments for Sutter's Mill
	Comment on GotW #89 Solution: Smart Pointers by Norbert Riedlin When I implement a class deriving from enable_shared_from_this, I usually make all constructors private and add static factory functions that create and return shared pointers to the class. As the constructors are private I cannot use make_shared in these factory functions but I have to resort to using new. At least this is true for boost::make_shared. I haven’t found a way like making some function or function template instantiation a friend of the said class to be able to use make_shared. Do I miss something? Read More » Comment on GotW #90 Solution: Factories by Marcel Wid @Johannes and @Herb: This is the first time that I think I understand when to write ‘return move’. But I think that this has nothing to do with copy elision in contrast to what Johannes is saying. In the following code optional<vector<gadget>> load_gadgets() noexcept { vector<gadget> ret; // ... populate ret ... return move(ret); // important: move() here to avoid a silent copy } ret is implicitely converted to optional<vector> by one of the following converting constructors of optional: constexpr optional(const T&) or constexpr optional(T&&) depending whether you write return ret; (for the former) or return move(ret); (for the latter). The result of this coversion is a temporary object, which is copied/moved into the function’s return value. An implementation is allowed to elide this last copy/move. Please correct me if I got it wrong. Read More » Comment on GotW #90 Solution: Factories by Vincent Jacquet I wonder why we should returning optional<vector>. If no widgets can be loading what’s the benefit compared to returning an empty vector. This way I do not introduce a special case. Also, when loading a single gadget, returning optional is only an option (pun intended). I could also return a default gadget or an error gadget. Read More »
	Delievered to you by Feedamail. Unsubscribe