From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-10-04 05:31:00
"Pavol Droba" <droba_at_[hidden]> wrote in message
| > | This would allow to easily (and naturaly) write most of the 'safe'
| > | algorithms.
| > are you suggesting to rewrite all the mutable standard algorithms?
| I'm not sure where are you heading? We are talking about sorts and
| and permutations. There are not so many of them. If they are provided
| as member functions, these would be one-line long. So it yeilds
| about 20-30 lines of code all together.
hm...we have at least
| Other mutating algorithms are not usable anyway.
| swap functionality would enable to write other 'safe' algorithms.
then maybe we need another iterator category, say,
and algorithms for it?
Anway, I don't feel implementing algorithms just for smart containers to be a
very good generic abstraction.
| > |
| > | > 3. we risk users will just do &*begin(), &*end() to get the pointers
| > anyway
| > | >
| > |
| > | If somebody would do this, it is more then clear, that there is a great
| > | potential
| > | for something to get wrong, unlike when you write
| > |
| > | std::remove(vec.ptr_begin(), vec.ptr_end(), ...)
| > |
| > | which seems very reasonable.
| > not if you know what remove does..
| > std::remove( vec.begin(). vec.end() )
| > will either fail at compile time or do it right.
| Are you sure about this?
1. this won't compile if the algorithm requires T to be copyable
2. if T is copyable, we need not worry about anything other than it could be
| The knowledge about remove algorithm is far not enough
| to comprehend how it would work in conjuction with ptr_iterator.
It won't work properly with ptr_iterator, that's how it is currently
There is AFAICT lots of places where you can go wrong in STL and C++ and this
does not seem particularly nasty to me. "Trust the programmer" as the old C++
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk