On 19.3.2012 16:43, Szymon Gatner wrote:
Hello boosters,
a design question: how often (if ever) and under which circumstances do you use shared_container_iterator?
(http://www.boost.org/doc/libs/1_49_0/libs/utility/shared_container_iterator....)
I don't feel too good about allocating a vector<> on the heap but I guess it was made for some reason and motivated by actuall need. What are good use cases for such iterator? Obviously returning a container from function (as presented in example) is not one of them.
Erm, why wouldn't it be a good idea? That put aside, shared_container_iterator comes handy when you need to return several values that are eg. picked up from a larger pool and/or otherwise modified (and thus can't directly return iterators as the contents needs to be allocated). You don't want to return a copy of vector and perhaps don't want to pass as an argument a target vector either. Having a local copy (that would be returned as a reference) isn't thread safe, so that one is one is kinda bad, too. Moreover, as vector is returned wrapped inside a shared_container_iterator (well, a pair of those) one may pass it directly to Boost.Range or Boost.Foreach (yep, std::pair supported) without spending too much time thinking when and how to allocate and release memory as shared_ptr does that for you. I don't really know why you should feel bad about allocating a vector from heap as std::allocator will use heap anyway. Not really seeing that operating vector from stack and it's contents from heap would be any faster than having the both allocated from heap. If I'd had to optimize (as in Optimize, not some needless micro optimizations) some vector / array related operation, I think I'd forget any std container, let alone shared_ptr, in the first place... -- Pekka