My area of programming is DSP. I write things like filters, oscillators,
envelopes, etc. I've been looking at STL iterators, and what's struck me is
that if I can find ways to model my code using STL's iterator conventions, I
could possibly make my code more economic while probably losing little to no
efficiency.
As an example, an oscillator will have a "phase accumulator." So typically
in a loop I will have something like this:
phaseAccumulato r += phaseIncrement;
if(phaseAccumul ator >= 1.0f)
{
phaseAccumulato r -= 1.0f;
}
output = waveform(phaseA ccumulator);
It occurred to me that I could have a phase accumulator iterator. My code
would turn into this:
phaseAccumulato r++;
output = waveform(*phase Accumulator);
Much more compact. Or even better:
std::transform( phaseFirst, phaseLast, outputBuffer, SineWaveform()) ;
Down to just one line of code. Ok, so far, so good. But there is a gray area
I'm concerned about.
I need to keep track of the phase. The phase is state that needs to persist
across iterations. This means that I need to give the iterator a pointer to
the phase variable when I create it so that as it's iterating, it's also
modifying the phase variable. Something like:
// Inside my Oscillator class somewhere:
it = PhaseIterator it(&phase, increment);
// Inside the PhaseIterator class:
PhaseIterator &operator++( )
{
*phase += increment;
if(*phase >= 1.0f)
{
*phase -= 1.0f;
}
return *this;
}
This works, but it means that I can only use one phase iterator at a time.
That's actually not a problem for me since the iterator is only being used
internally by the Oscillator class, but my question is whether this violates
the spirit of STL iterators. Is there a category of iterators (Input
Iterators, perhaps?) that restrict you to using only one iterator at a time
over a collection?
Advancing an iterator doesn't usually involve changing the collection the
iterator belongs to. However, in this case, the collection is the phase
values belonging to the oscillator; the iterator is actually generating the
phase values that drive oscillation. I like this approach, but was wanting
to get some thoughts on this from others.
envelopes, etc. I've been looking at STL iterators, and what's struck me is
that if I can find ways to model my code using STL's iterator conventions, I
could possibly make my code more economic while probably losing little to no
efficiency.
As an example, an oscillator will have a "phase accumulator." So typically
in a loop I will have something like this:
phaseAccumulato r += phaseIncrement;
if(phaseAccumul ator >= 1.0f)
{
phaseAccumulato r -= 1.0f;
}
output = waveform(phaseA ccumulator);
It occurred to me that I could have a phase accumulator iterator. My code
would turn into this:
phaseAccumulato r++;
output = waveform(*phase Accumulator);
Much more compact. Or even better:
std::transform( phaseFirst, phaseLast, outputBuffer, SineWaveform()) ;
Down to just one line of code. Ok, so far, so good. But there is a gray area
I'm concerned about.
I need to keep track of the phase. The phase is state that needs to persist
across iterations. This means that I need to give the iterator a pointer to
the phase variable when I create it so that as it's iterating, it's also
modifying the phase variable. Something like:
// Inside my Oscillator class somewhere:
it = PhaseIterator it(&phase, increment);
// Inside the PhaseIterator class:
PhaseIterator &operator++( )
{
*phase += increment;
if(*phase >= 1.0f)
{
*phase -= 1.0f;
}
return *this;
}
This works, but it means that I can only use one phase iterator at a time.
That's actually not a problem for me since the iterator is only being used
internally by the Oscillator class, but my question is whether this violates
the spirit of STL iterators. Is there a category of iterators (Input
Iterators, perhaps?) that restrict you to using only one iterator at a time
over a collection?
Advancing an iterator doesn't usually involve changing the collection the
iterator belongs to. However, in this case, the collection is the phase
values belonging to the oscillator; the iterator is actually generating the
phase values that drive oscillation. I like this approach, but was wanting
to get some thoughts on this from others.