
Boost : 
Subject: Re: [boost] [odeint] Documentation comments
From: Karsten Ahnert (karsten.ahnert_at_[hidden])
Date: 20120927 01:11:20
On 09/27/2012 01:42 AM, John Bytheway wrote:
> On 25/09/12 22:38, Mario Mulansky wrote:
>> John Bytheway <jbytheway+boost_at_[hidden]> wrote:
>>> The more general idea of automatically dispatching to the right
>>> algebra is more dangerous, because for example it is entirely
>>> possible to have a type which is both a Fusion sequence and a Range
>>> (but with different semantics in each interpretation). So, I am not
>>> suggesting that (though I wouldn't argue against it either).
>>
>> This would be an edge case where explicit user definition is
>> required, but i think in 99% an algebra dispatcher would be
>> sufficient.
>
> On further reflection I thought of a particular case where this happens.
> Any std::pair<Iterator, Iterator> is both a Fusion Sequence and a Range,
> with very different semantics. Just something to consider.
Having a range as state_type is difficult maybe even impossible, since
ranges can not be resized. A range models something that already exists
and inside the stepper a temporary must be created. (But a range can be
passed to the do_step method.)
Nevertheless, it is possible the create a dispatcher like
template< class State , class Enabler = void >
struct algebra_dispatcher;
template< class T , class A >
struct algebra_dispatcher< std::vector< T , A > , void >
{
typedef range_algebra type;
};
// this will create errors for ranges of pairs of iterators
template< class R >
struct algebra_dispatcher< R ,
typename boost::fusion::is_sequence< R >::type >
{
typedef fusion_algebra type;
};
The steppers simply get the value of the algebra dispatcher as a default
parameter:
template< class State , ... ,
class Algebra = typename algebra_dispatcher< State >::type ,
... >
struct stepper { ... };
Then, the user will mostly get the right algebra, and in case this is
not possible he can easily specify the desired one. (The same should be
done for the operations.)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk