Re: Non-container Iterators
On Jul 24, 11:18 pm, "Leslie Sanford" <jabberdab...@bitemehotmail.com>
wrote:
In this case, there is no sentinel iterator as an oscillator, which a pha=
se
accumulator drives, can cycle indefinitely, a kind of circular buffer, I
suppose.
Is it acceptable for an iterator to never reach an "end"? I would have
another way for testing for the end of the loop, specifically the end of =
the
buffer that I'm filling. I should be able to increment the phase iterator
indefinitely.
while(first != last)
{
*first = *phase;
phase++;
first++;
}
Since (triple) posting, I've been giving this approach some thought, and =
I
was wondering if a Generator would be a more appropriate model than an
Iterator to represent a phase accumulator.
http://www.sgi.com/tech/stl/Generator.html
class PhaseAccumulator
{
public:
typedef float result_type;
private:
float phase;
float increment;
public:
PhaseAccumulator(float phase, float increment)
{
this->phase = phase;
this->increment = increment;
}
result_type operator()()
{
phase += increment;
if(phase >= 1.0f)
{
phase -= 1.0f;
}
return phase;
}
};
I can have a Square waveform represented as a unary function:
typedef std::unary_function<float, float> WaveShapeBase;
struct Square : public WaveShapeBase
{
result_type operator()(argument_type phase) const
{
assert(phase >= 0.0f && phase < 1.0f);
return phase < 0.5f ? -1.0f : 1.0f;
}
};
And use both in a loop to fill a buffer:
class Oscillator
{
PhaseAccumulator phase;
Square wave;
public:
// Stuff...
void Process(float *first, float *last)
{
while(first != last)
{
*first = wave(phase());
first++;
}
}
}
Maybe this is a more appropriate approach given the concepts involved?
Since the phase can't "end" in any meaningful sense, a generator may
be a more appropriate design pattern. Pseudo-random number generators
(eventually) loop, too, and they're commonly used as generator
functors. That being said, there certainly are generator-style
iterators out there, e.g. boost::counting_iterator:
http://www.boost.org/doc/libs/1_35_0/libs/iterator/doc/counting_iterator.ht=
ml
Using something like that approach, your oscillator class might look
like:
void Oscillator::Process(float *begin, float *end)
{
// Generate
std::transform(
phase.begin(),
phase.end( std::distance(begin,end) ),
begin,
Square );
}
I assume the phase has been given counting_iterator-like support,
where the end() function takes a parameter telling it how many times
to increment. Note also that you could convert your square wave
functor to an ordinary function with the signature float Square(float)
since it doesn't take any constructor parameters or maintain mutable
state. The member variable for that functor is overkill.
The down-side to this approach is that the use of std::transform()
with a generator-style iterator to generate is takes some thinking,
and one of our goals for code is (or, should be) to make it readable.
The names of the standard functions are intended to communicate your
meaning rather than obscure it (cf. http://www.ddj.com/cpp/184401446),
but generator-style iterators cut against the grain in a circumstance
like this.
A generator approach: Using functional composition [let's call ours
my_compose(f,g) = f(g())], whose implementation is relatively
straightforward and similar to the common extension to the STL (e.g.,
http://www.sgi.com/tech/stl/unary_compose.html), one can make this
clearer on first reading:
std::generate( begin, end, my_compose( Square, phase ) );
Now fewer tricks are being played, and its meaning should be clearer
to someone reading your code down the line (which could be you).
Cheers! --M