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

Subject: Re: [Boost-users] [Iterator] shared_container_iterator usability
From: Szymon Gatner (szymon.gatner_at_[hidden])
Date: 2012-03-19 12:28:07

> Erm, why wouldn't it be a good idea?

Because one would normally just return a function-local vector by
value which is much cheaper (with move semantics) then heap allocation
of a container + 2 x shared_ptr construction.

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

All well supported also with just returning a container by value.

>
> I don't really know why you should feel bad about allocating a vector from
> heap as std::allocator will use heap anyway.

This way you get 2 heap allocations + shared_ptr<> construction as
opposed to just internal allocation of vector (using allocator). This
is especially bad if returned vector turns out to be empty. In that
case vector might not do allocation at all so vector creation and
return are practically free.

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

Interesting. What would you use instead of a vector + specfic
allocator when "Optimizing"? Continuous block of memory is rather hard
to beat in terms of data processing speed.

Anyway, still not convinced of good use case ;) Is there any?

Cheers