[boost] Re: Re: Re: Re: [review] Formal review of theSmartContainerlibrarystarts today (long)

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-10-04 05:31:00

"Pavol Droba" <droba_at_[hidden]> wrote in message
news:20041004094558.GX9207_at_lenin.felcer.sk...

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

swap_ranges()
ramdom_shuffle()
sort*()
stable_sort*()
partial_sort*()
nth_element*()
push_heap*()
pop_heap*()
prev_permutation*()
next_premutation*()

| Other mutating algorithms are not usable anyway.
|
| swap functionality would enable to write other 'safe' algorithms.

then maybe we need another iterator category, say,
swap_only_iterator_category,
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
slow

| 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
situation
does not seem particularly nasty to me. "Trust the programmer" as the old C++
matra goes.

br

Thorsten