[ptr_container] indirect_fun - do we still need it?
Thorsten, Now, when we got rid of ptr_iterators, we don't need indirect_fun, do we? At least as part of ptr_container library? P.S. About copyability: may be then provide some cloning mechanism like: ptr_vector<int> a; ptr_vector<int> b(a.clone()); b = a.clone(); Where ptr_vector<T>::clone doesn't create clone immeadiately, but returns some object that refers to this, and ptr_vector<T> has ctor and assignment operator taking that object. Thoughts? -- Pavel Chikulaev
"Pavel Chikulaev" <pavel.chikulaev@gmail.com> wrote in message news:d5ig27$kjm$1@sea.gmane.org... | Thorsten, | | Now, when we got rid of ptr_iterators, we don't need indirect_fun, do we? | At least as part of ptr_container library? you might still need it if you do std::sort( vec.begin().base(), vec.end().base(), void_ptr_indirect_fun<std::less<T>,T>() ); but I would like to see the stuff being put into a better maintained utility if somebody is volunteering. | P.S. About copyability: may be then provide some cloning mechanism like: | | ptr_vector<int> a; | ptr_vector<int> b(a.clone()); | b = a.clone(); | | Where ptr_vector<T>::clone doesn't create clone immeadiately, but returns some | object that refers to this, and ptr_vector<T> has ctor and assignment operator | taking that object. | | Thoughts? I'm not sure what you're trying to achieve. and when is the clone then created? -Thorsten
"Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message news:d5qspk$ap3$1@sea.gmane.org...
but I would like to see the stuff being put into a better maintained utility if somebody is volunteering.
boost::utility would be a good place for it, I guess.
I'm not sure what you're trying to achieve. and when is the clone then created?
As I said in private e-mail, that was not good idea and we won't achieve nothing with it. But only if you make ptr_container::operator = (auto_ptr<ptr_container>) works as expected. -- Pavel Chikulaev
"Pavel Chikulaev" <pavel.chikulaev@gmail.com> wrote in message news:d5rflt$ahg$1@sea.gmane.org... | But only if you make | ptr_container::operator = (auto_ptr<ptr_container>) works as expected. there should be void ptr_container::operator=( auto_ptr<ptr_container> ) already. Is it not what you expect? -Thorsten
"Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message news:d5sfp7$ogk$1@sea.gmane.org...
there should be
void ptr_container::operator=( auto_ptr<ptr_container> ) already. Is it not what you expect?
You've said about assignment operator the following:
well, it does lead to a conversion sequence instead of a direct call to the constructor, so it might not be that bad >to add the operator.
So my comment was based on that statement. BTW what's the rationale returning void instead of ptr_container & ? -- Pavel Chikulaev
"Pavel Chikulaev" <pavel.chikulaev@gmail.com> wrote in message news:d5tl91$plq$1@sea.gmane.org... | "Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message | news:d5sfp7$ogk$1@sea.gmane.org... | > there should be | > | > void ptr_container::operator=( auto_ptr<ptr_container> ) already. Is it not | > what you expect? | | You've said about assignment operator the following: | >well, it does lead to a conversion sequence instead of a direct call to the | >constructor, so it might not be that bad >to add the operator. | | So my comment was based on that statement. that statement was made before I realized that I already had such an operator. | BTW what's the rationale returning void instead of ptr_container & ? what do you need the returned reference for? -Thorsten
participants (3)
-
Arkadiy Vertleyb -
Pavel Chikulaev -
Thorsten Ottosen