[boost] Re: Boost I/O Library review status

From: Ed Brey (brey_at_[hidden])
Date: 2003-03-19 15:49:29

Gennaro Prota wrote:
> 
>> Mis-use of endl doesn't seem to be adequet justification for a new
>> end-of-line specifier.  However, a difference in behavior between
>> '\n' and endl does.
> 
> Indeed. And there are obvious differences:
> 
> http://article.gmane.org/gmane.comp.lib.boost.devel/17737

I remember that post, and also remember only understanding to some extent.  I was hoping that Daryle might write up a rationale that put the difference in closer to layman's terms.  I looked for some discussion on the topic in Stroustrup's C++ Programming Language, but couldn't find any anything to clarify.  Could you elaborate on when '\n' invokes a special behavior that endl would not and what that behavior is?

>> True.  Presumably, then, the same subtle effects that would compel an
>> alternative to '\n' wouldn't do likewise for '\t'.  Is that correct?
> 
> The effect is exactly the same and there's nothing subtle about it.

I borrowed the term "subtle" from Daryle, although it applies to my view right now since I don't understand the difference between '\n' and endl.  Once I understand the distinction, I may well agree.

> BTW, a non-flushing endl, as well as almost everything has been
> proposed here, are plain classics. Apart from the hundreds of
> newsgroup questions about '\n' vs. endl, I remember dozens of articles
> about array based stream buffers for instance. I don't have time to
> search for pointers right now (some of them were in CUJ) and,
> unfortunately, I don't think I would search them even if I could.
> Judging from the replies I got, seems like I've already wasted enough
> time with the review:
> 
> http://article.gmane.org/gmane.comp.lib.boost.devel/17500

Please don't be discouraged.  This review is definately proceeding very slowly; however, I fully expect that Daryle will address each reviewer's comments in detail.  Your criticisms bring important points to light, of which I only highlighted in the most high-level fashion in my review status summary.  From my examination of the code, there may well be good counterarguments that could render the stream buffer wrapping library worth keeping, but I'll let Daryle make these arguments for himself and observe how the discussion goes.

Daryle, to ease reviewers' minds, perhaps you could provide an idea from a timing perspective of when you'll be able to address the specific review comments.