Re: [Boost-users] [Iterator] shared_container_iterator usability

Subject: Re: [Boost-users] [Iterator] shared_container_iterator usability
From: Pekka Seppänen (pekka.seppanen_at_[hidden])
Date: 2012-03-19 11:41:03

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.html)
> 
> 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