FeedaMail: Comments for Sutter’s Mill

	Comments for Sutter's Mill
	Comment on GotW #91 Solution: Smart Pointer Parameters by Mathias Stearn What do you think of using something like ptr [1] which is usable like a T* but is implicitly convertible from any smart pointer and clearly marks non-owning semantics? I’ve found that in code that uses smart pointers, functions that take a bare pointer are annoying because you have to call get(), breaking the abstraction. It also has a nice side benefit of less visual ambiguity between const ptr and ptr. On the related issue of pointer returns, do you know why covariant return support wasn’t added for smart pointers? It seems like a clone() method would have to choose between better type-safety but using a raw owning pointer or returning a smart pointer and requiring casts. [1] https://gist.github.com/RedBeard0531/5736292 (written for C++98 + boost) Read More » Comment on GotW #92 Solution: Auto Variables, Part 1 by Mathias Stearn It might be worth adding the following examples. After reading this article I felt the need to test these cases since auto expands to “const int” which does have a top-level const even though the full types of g2 and h2 don’t. const int ci = val; auto g = ci; auto& g2 = ci; const int& cir = val; auto h = cir; auto& h2 = cir; Also, I’m curious about auto&&. I think it would only be an rvalue-ref when the right hand side was a value or rvalue-ref returned from a function. Is there any detail I’m missing? Read More » Comment on GotW #93: Auto Variables, Part 2 by afrantzis 1(a) The code is incorrect, since we are trying to get a non-const iterator to a const container. By using auto we would have avoided this programming error; the expected (and safe) const_iterator type would have been chosen. Read More » Comment on GotW #93: Auto Variables, Part 2 by mttpd That’s a good catch, afrantzis! After thinking about it, this makes me tend to prefer the index-based solution (with std::size_t) or even better Boost.Range one (it’s better and IMO is to be preferred since it’s less error-prone and more expressive, analogously to how using STL algorithms is less error-prone & more expressive than hand-coded loops in general) — since, in addition to auto, I think we should also use std::cbegin and std::cend (from C++14) instead of their non-const counterparts. Read More » Comment on GotW #93: Auto Variables, Part 2 by mttpd Correction: no, std::cbegin or std::cend won’t be necessary here, since the argument’s type is already const and thus the right, const-correct overloads of std::begin and std::end shall be chosen. Read More »
	Delievered to you by Feedamail. Unsubscribe