No, state is not duplicated while the algorithm traversing a sequence. The inner loop uses the same instance of output iterator. But actually in practice I use totally different approach.

template <typename CharT = char>
class smart_separator
{
    using ostream_type = basic_ostream<CharT, char_traits<CharT>>;
 
public:
    smart_separator(const CharT* value) : value_(value), first_(true) { }
 
    friend ostream_type& operator <<(ostream_type& os, smart_separator& sep) {
        if (sep.first_) sep.first_ = false; else os << sep.value_;
        return os;
    }
 
private:
    const CharT* value_;
    bool         first_;
};
 
int main()
{
    vector<int> numbers = {1, 2, 3, 4, 5};
 
    smart_separator<> sep(",");
    for (auto number : numbers) cout << sep << number;
}

If it’s copied once when passing it to the algorithm it’s fine, but if the algorithms can hold several instances of the output iterator the state would indeed be duplicated.
Anyway that’s a nice trial. I’m sure that’s the starting point of a better solution. Maybe with std::ref? Or it that overkill?

Unfortunaly, no. Iterator is copied every time. Moreover, if it’s non-copyable, the code won’t compile at all.

Neat! I like the idea.
Do you know if the STL algorithms are sure not to copy the output iterator (to be sure that the state “first_” stays consitently in one place)?

template <typename T, typename CharT = char>
class infix_ostream_iterator : public iterator<output_iterator_tag, void, void, void, void>
{
    using self_type = infix_ostream_iterator<T, CharT>;
    using ostream_type = basic_ostream<CharT, char_traits<CharT>>;
 
public:
    infix_ostream_iterator(ostream_type& os, const CharT* sep)
        : os_(os), sep_(sep), first_(true)
    { }
 
    self_type& operator*() { return *this; }
    self_type& operator++() { return *this; }
 
    self_type& operator=(const T& item) {
        if (!first_) os_ << sep_; else first_ = false;
        os_ << item;
 
        return *this;
    }
 
private:
    ostream_type& os_;
    const CharT*  sep_;
    bool          first_;
};

My bad.
“It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so”

If this particular situation >loading a file’s contents into a std::string< had cropped up in a real project am working on, I would have introduced a subtle bug… thanks for calling me out its how we learn

to_string was added in C++11 so it’s in “modern C++” 🙂 I see your point, and I’m not sure why this isn’t an overloaded function template.

Avoid strong advice. Especially if untested. Why not hit the docs or try it? http://coliru.stacked-crooked.com/a/2f8afdcc448eda09

But were to_string written today, would the committee make it a template function (to allow extending it to custom types) ?

ostream_joiner (suggested by sv90 in the above comment) looks good to me. Additionally range-v3 has intersperse doing a similar feature I reckon.