It's interesting (odd?) that the interface doesn't just expose a function to get the next value, similar to a lazy list in Haskell, which also goes well with the original statement in the post that a stream is basically a function. The 'sine_wave' stream for example is 90% filling the array and 10% actual stream logic, which I imagine you're duplicating in other stream implementations.
C++ audio mixing library design
51–54 of 54 posts
Re: C++ audio mixing library design
#52> The stream interface is the core of the library, so let’s discuss it first. It is remarkably simple It's interesting (odd?) that the interface doesn't just expose a function to get the next value, similar to a lazy list in Haskell, which also goes well with the original statement in the post that a stream is basically a function. The 'sine_wave' stream for example is 90% filling the array and 10% actual stream logi…
Re: C++ audio mixing library design
#53Earlier quoted context omitted.
std::span is new enough to not be in muscle memory of C++ programmers. Even the standard library commits a similar sin with `from_chars` and not taking a `string_view`.
string_view would definitely have been wrong. std::span did not exist in the Standard at the time std::from_chars was adopted. An overload that takes std::span would be easy, and harmless. But as std::from_chars is only ever used from within some other abstraction, any benefit would be minimal.
Re: C++ audio mixing library design
#54Earlier quoted context omitted.
string_view would definitely have been wrong. std::span did not exist in the Standard at the time std::from_chars was adopted. An overload that takes std::span would be easy, and harmless. But as std::from_chars is only ever used from within some other abstraction, any benefit would be minimal.
Why would string_view be wrong there?