|
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