Boost logo

Boost :

From: John Torjo (john.lists_at_[hidden])
Date: 2003-11-19 23:57:16


>>template<class T> void f( const T&) {}
>>template<class T> void f( T&) {}
>>const std::deque<int> d;
>>f(d); // compile-time error in VC6
>
>
> true. that's why the collection traits allows you to remedy this.
> You simply provide one function wuth a T& argument and
> use some metaprogramming to figure out the rest. You do loose the
> probability to use rvalues, but vc6 users just have to accept that.

The point is that this can be remedied like this:

#ifndef BOOST_VC6_WORKAROUND
template<class T> void f( const T&) {}
#endif
template<class T> void f( T&) {}

for it to work correctly for VC6.

>>rng::erase( m_snapshots, rng::unique( m_snapshots, snapshot_eq_time) );
>>
>>The above line uses ::std::unique to remove the duplicates (move them to
>
> the end
>
>>of the range, and returns then range of elements to be erased. Then
>
> rng::erase
>
>>calls m_snapshots.erase( remaining_range);
>
>
> m_snapshots.erase( boost::unique( m_snapshots, snapshot_eq_time ),
> m_snapshots.end() );
>
> or with Pavols algos
>
> erase_range( m_snapshots, make_iterator_range( unique( m_snapshots,
> snapshot_eq_time ), m_snapshots.end() ) );
>

indeed, but quite a few more keys to type;)
redundant also

> which could certainly be better. Maybe we need an erase_from(), erase_util()
> took a single iterator?

I'm not sure I understand...

>>// taken from real-life code
>>if ( get_account_history().pending_orders().find( order_id) !=
>>get_account_history().pending_orders().end() )
>
>
> seriously, you're joking right? I would definitely make a temporary or
> make a function that gave me the pending_orders. real life should never be

Only for one question? (an if)

> more complicated than
>
> order_t orders = ...;
> if( orders.find( order_id ) != orders.end() )
>
> if it is, something else is wrong and a refactoring needs to be done.

I'm not sure about this. You're highly optimistic in this matter;)

>
> Please imagine
>
// missing typedef ;)
> order_t orders = get_account_history().pending_orders();
> some_range_class r( boost::find_if( orders, pred), orders.end() );
>
>
>>compared to:
>>some_range_class r = rtl::find_if(get_account_history().pending_orders(),
> pred));

Now, I'm not saying it's not possible, but it's just much easier to use the latter.

>>default, and if specified like rtl::find_if<to_end>, return a range.
>>
>[...]
> It seem ok, but I don't feel it's quite there. The hard thing must be to get
> it down to a
> minimum of algortihms.
They're not many - just look at the algorithm that return an iterator (other
than the output iterator)

>
> ok, then if we had erase_XX we could do
>
> erase_from( c, std::unique( c ) );
> erase_to( c, std::unique( c ) );
>
I'm not sure I understand.

>[...]
> not an operator bool(), but something convertible to bool (like a pointer to
> a member) to prohibit misuse.
fair enough. But will this compile:
if ( r1 && r2) ... // r1 and r2 are ranges

Best,
John


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk