I think that ideally, ostream_iterator's operator=() should write the
delimiter *between*
elements and not after them.

One way of doing this:

Add a default int argument = 0 to ostream_iterator's constructor and
save the value
in a member variable counter. Then, in operator=(),

if (++counter == 1)
os << value;
else
os << delimiter << value;
}

Given that "1,2,3,4,5" is a more natural way to write a list than
"1,2,3,4,5,",
is there a particular reason why they did not do it that way?

I suppose that there should also be a method to reset the counter, or
it could be
defined that you cannot reset it, and you must instead create a new
ostream_iterator
if you want to start a new sequence.

On Dec 6, 5:21 pm, johnbrown...@hotmail.com wrote:
> I think that ideally, ostream_iterator's operator=() should
> write the delimiter *between* elements and not after them.

That's probably more generally useful. Sometimes you want a
terminator, and sometimes you want a separator. If you want a
terminator, but the iterator implements separator, it's easy to
add a final terminator; but if you want a separator, and the
iterator implements terminator, you're stuck---there's no way to
remove something once it's been inserted into the stream.

But this doesn't solve all of the problems, either. Typically,
you need a lot more formatting information. Say, the number of
elements in a line, text to insert before the first element in a
line, text to insert after the last (typically empty), as well
as the separator.

> One way of doing this:

It would be easy to implement. Handling the case of multiline
output (necessary for anything but the shortest sequence) would
be more difficult, but I think it would also be doable.

> Given that "1,2,3,4,5" is a more natural way to write a list than
> "1,2,3,4,5,",
> is there a particular reason why they did not do it that way?

Maybe they were considering sequences of strings, one to a line?
Or they were thinking of machine generated code---C and C++
explicitly allow an extra comma at the end of initializer lists,
for example, precisely so that the simplest situation will work
for code generation.

Maybe no one had actually used it in real applications at the
time it was standardized, so no one had any real idea as to what
was needed?

> I suppose that there should also be a method to reset the
> counter, or it could be defined that you cannot reset it, and
> you must instead create a new ostream_iterator if you want to
> start a new sequence.

I find that in practice, almost every time I'm outputting a
sequence, I'm using something like:

int const maxPerLine = whatever ;
int inLine = 0 ;
while ( begin != end ) {
if ( inLine == 0 ) {
dest << " " ;
} /* sometimes */ else {
dest << " " ;
}
dest << std::setw( n ) << *begin ;
++ begin ;
if ( begin != end ) {
dest << separator ;
}
++ inLine ;
if ( inLine == maxPerLine ) {
dest << '\n' ;
inLine = 0 ;
}
}

I do this offen enough that I'm seriously thinking about
developping some sort of generic solution for it.

On the other hand, about the only time I do it today is for code
generation. And while it's necessary if you want the code to
look pretty, the compiler doesn't care (the direct output of
ostream_iterator would be fine), and no one else should really
have to read it. In the past, with primitive printers and
CRT's, I'd use this anytime I wanted a table, but today, if it's
for the screen, I'll use some sort of layout manager, formatting
each field separately, and if it's for the printer, I'll output
something like:
\begin{tabular}{rrrr}
1&2&3&4\\
abc&def&ghi&jkl\\
\end{tabular}
for the printer front-end (normally LaTeX, since I want the
printed output to look good). I suspect that in the near
future, the output will be XML, with various front-ends to
convert it to whatever is needed.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34