On 5/25/07, Seweryn Habdank-Wojewódzki wrote:

# sobota 26 maja 2007 02:14, @ Felipe Magno de Almeida:

...

Use ptr_vector

Thanks

Btw why there is no way to work with it like that:

ptr_vector<Foo> g; g.push_back ( new Foo(1,k) );

ptr_vector d; d.push_back ( new ptr_vector<Foo> ( g ) );

Because ptr_vector is not copy-constructable. That is the same reason why you can't use it inside a STL container.

I should do like that:

ptr_vector<Foo> g; g.push_back ( new Foo(1,k) );

ptr_vector d; d.push_back ( new_clone ( g ) );

Regards.

--

|\/\/| Seweryn Habdank-Wojewódzki \/\/

Regards, -- Felipe Magno de Almeida

Hi!

d.push_back( g.clone() );

...

Because ptr_vector is not copy-constructable. That is the same reason why you can't use it inside a STL container.

In 1.35 I plan to change this so all ptr containers can be copied.

OK. I understand.

I still don't recommend vector< ptr_vector<T> >, but I'll let the user decide when he wants to copy.

This is reasonable. My point of view touch the constant fields. So blocking assignment is still useful, because in fact many fields are constant, but copy is allowed for constant fields. Thanks for all for the help. Regards. -- |\/\/| Seweryn Habdank-Wojewódzki \/\/

On 26/05/07, Constantin Bryzgalin wrote:

Hello,

...

Can anyone tell me why std::vector < boost::ptr_vector < T > > can not be reserved and resized I can not push_back anything inside vector, due to compile errors?

well, creating a copy of ptr_vector raises question of pointer ownership. which one of copies will be responsible for releasing it? if object is to be deleted when it has no referring pointers it looks pretty much like boost::shared_ptr approach. thus if we come to idea of using shared_ptr there seems to be no more reason to use ptr_vector, what you want is std::vector< std::vector< boost::shared_ptr<T> > > instead.

My understanding is that copying a ptr_container will (once made legal) result in the cloning of all of its elements, which means that there is no ownership problem, but that it's quite expensive (which is why it's been prohibited). ~ Scott McMurray

On 28/05/07, Mark Ruzon wrote:

I would hope that no one who writes useful algorithms tries to prohibit reasonable actions from taking place just because they're expensive. It is not up to library designers to save programmers from themselves; programmers can always write inefficient code if they choose not to think carefully about what they're doing. This is one of the founding principles of the Standard Template Library, and one that should continue to guide Boost.

From what he said earlier, it appears Thorsten Ottosen now agrees: "In 1.35 I plan to change this so all ptr containers can be copied. I still don't recommend vector< ptr_vector<T> >, but I'll let the user decide when he wants to copy."

I suppose it's also plausible that SFINAE problems in compilers that will no longer be supported in 1.35 were partly to blame.