[ptr_vector] vector<ptr_vector < T > >
Hi! 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? I am using ptr_vector for storing copyable, but nonassignable objects of type T - in fact objects contains mainly const elements. Regards. #include <iostream> #include <vector> #include <boost/ptr_container/ptr_vector.hpp> class Foo { public: Foo ( int const i, int const & j ) :i_(i), j_(j) {} Foo ( Foo const & f ) : i_(f.i_), j_(f.j_) {} private: int const i_; int const & j_; void operator= ( Foo const & f ); }; int main() { using namespace std; using namespace boost; int k = 10; ptr_vector<Foo> g; g.push_back ( new Foo(1,k) ); vector<ptr_vector<Foo> > d; //d.push_back ( g ); <-- Errors //d.resize(5) //d.reserve(5) } -- |\/\/| Seweryn Habdank-Wojewódzki \/\/
Use ptr_vector<ptr_vector<T> > On 5/25/07, Seweryn Habdank-Wojewódzki <shw@agh.edu.pl> wrote:
Hi!
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?
I am using ptr_vector for storing copyable, but nonassignable objects of type T - in fact objects contains mainly const elements.
Regards.
#include <iostream> #include <vector> #include <boost/ptr_container/ptr_vector.hpp>
class Foo { public: Foo ( int const i, int const & j ) :i_(i), j_(j) {}
Foo ( Foo const & f ) : i_(f.i_), j_(f.j_) {}
private: int const i_; int const & j_; void operator= ( Foo const & f ); };
int main() { using namespace std; using namespace boost;
int k = 10; ptr_vector<Foo> g;
g.push_back ( new Foo(1,k) );
vector<ptr_vector<Foo> > d; //d.push_back ( g ); <-- Errors //d.resize(5) //d.reserve(5) }
--
|\/\/| Seweryn Habdank-Wojewódzki \/\/ _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Felipe Magno de Almeida
# sobota 26 maja 2007 02:14, @ Felipe Magno de Almeida:
Use ptr_vector<ptr_vector<T> >
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<ptr_vector<Foo> > d; d.push_back ( new ptr_vector<Foo> ( g ) ); I should do like that: ptr_vector<Foo> g; g.push_back ( new Foo(1,k) ); ptr_vector<ptr_vector<Foo> > d; d.push_back ( new_clone ( g ) ); Regards. -- |\/\/| Seweryn Habdank-Wojewódzki \/\/
On 5/25/07, Seweryn Habdank-Wojewódzki <shw@agh.edu.pl> wrote:
# sobota 26 maja 2007 02:14, @ Felipe Magno de Almeida:
Use ptr_vector<ptr_vector<T> >
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<ptr_vector<Foo> > 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<ptr_vector<Foo> > d; d.push_back ( new_clone ( g ) );
Regards.
--
|\/\/| Seweryn Habdank-Wojewódzki \/\/
Regards, -- Felipe Magno de Almeida
Felipe Magno de Almeida skrev:
On 5/25/07, Seweryn Habdank-Wojewódzki <shw@agh.edu.pl> wrote:
# sobota 26 maja 2007 02:14, @ Felipe Magno de Almeida:
Use ptr_vector<ptr_vector<T> > 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<ptr_vector<Foo> > d; d.push_back ( new ptr_vector<Foo> ( g ) );
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. I still don't recommend vector< ptr_vector<T> >, but I'll let the user decide when he wants to copy. -Thorsten
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 \/\/
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. -- Constantin Bryzgalin http://www.oneclicktools.com
On 26/05/07, Constantin Bryzgalin <constb@tomsk.ru> 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
me22 <me22.ca <at> gmail.com> writes:
On 26/05/07, Constantin Bryzgalin <constb <at> tomsk.ru> 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.
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).
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. Mark Ruzon
On 28/05/07, Mark Ruzon <mark34@cs.stanford.edu> 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.
participants (2)
-
Constantin Bryzgalin -
Felipe Magno de Almeida -
Mark Ruzon -
me22 -
Seweryn Habdank-Wojewódzki -
Thorsten Ottosen