Re: Dummy streams: eating std::endl?
denise.kleingeist@googlemail.com wrote:
kanze wrote:
denise.kleingeist@googlemail.com wrote:
You shouldn't do this in the first place! Your Ignore_Stream
is not a stream and to me it doesn't even feel like one: for
example, you cannot pass it to a function declared like this:
void function(std::ostream& out);
So. There are lots of cases where using a wrapped stream is
appropriate---something that feels like a stream, and supports
<<, but isn't an ostream. I use it systematically for logging,
for example.
... and you don't want your logging facilities be usable for
things were a function is just appropriate?
For example? The stream wrapper is a temporary, and its
lifetime determines the extent of a record in the log---in a
multithreaded context, it holds a lock, so that data from other
log records doesn't get mixed in. If for some reason you
absolutely need to call a function taking an ostream& (it's
never happened to me), then you can get at the underlying
stream, and pass it. After checking for null, obviously,
because one of the jobs of the wrapper is to turn off logging.
I routinely find myself in the need to set up stream options
even for logging and not everything can easily be set up with
inserters: pword() and iword() parameters are just examples.
That's what manipulators are for. Write the necessary
manipulator, if you need it. I've never needed anything but
default formats for logging; by definition, almost, a log isn't
really formatted. But I guess that there could be exceptions.
And I test my loggers with manipultators, to be sure that they
work, even if I don't think the feature has ever been used.
In these cases it is rather convenient to delegate to a
function doing the suitable logging.
If the function knows it is only for logging, it can take a
LogOstream, rather than a stream. Otherwise, you have to do
something like:
{
LogOStream log( getLog() ) ;
if ( log.stream() != NULL ) {
function( *log.stream() ) ;
}
}
(The extra braces are necessary to limit the lifetime of the
LogOStream object.)
If the logging facility does not use an std::ostream, the
function to delegate to has to be a template or be overloaded
for all stream-like entities I might want to use it with.
Which are?
In fact, I do use a number of stream-like entities. But they
normally have different semantics, e.g. XDR formatting, or such.
So you need a different function anyway. Logging isn't quite so
extreme, but generally speaking, functions which do user
oriented output are too verbose for logging output, so you won't
want to use them anyway.
Better to stick with an std::ostream, I think. Admittedly,
there is a tiny complication with using streams: these have to
be bindable to non-const references, i.e. you can't use
rvalues. This is, however, easily avoided by using a class
(derived from std::ostream in case you use one of the built-in
types immediately in which case the object already supports
appropriate operations) providing a member function to
retrieve a non-const std::ostream reference:
std::ostream& logstream::ref() { return *this; }
Once this is in place, I haven't found any good reason to use
a wrapper but I was bitten more than once by having to use a
class like this.
You still have the problems of managing log levels, locking when
logging, etc. You haven't begun to have a logging system which
works.
Why don't you just create a null-stream:
std::ostream(0) << "this does nothing" << std::endl;
Because any decent code which writes to the stream will check
for errors, and such a stream will have an error status.
Do you really check the result of logging debug messages (or
infos, warnings).
Of course not. But if I know I'm logging, I know that I'm
dealing with a LogOstream, and not an std::ostream. Any program
which takes an ostream& does to check for errors; that's part of
the abc's of writing robust code.
What does your logging facility do when it fails to log what
it's supposed to log? Logging the error is probably not going
to work! You might increase some attached level but if
something as basic as writing to an (open) stream fails to
work, I'd say all bets are off for your logging. Yet, there is
no reason why the entire application should be in a bad state:
just because the partition with the with the log files is full
(well, a shop where this can happen unnoticed is in trouble in
the first place) doesn't mean that nothing is working.
So you admit that you can't use normal functions which take an
std::ostream& for log output. Because any normal function will
check for errors, and log them. Which sort of shoots a hole in
your arguments in favor of std::ostream in such cases.
That said, I would be surprised if the use of a stream wrapper
changes anything with respect to error checking anyway. The
primary reason I have seen for creating stream wrappers is
plain ignorance, playing with a new toy (templates), or - most
likely - a combination of both.
The primary reason for using a wrapper is to make logging as
simple as possible for the user. There is usually even a macro
above it, to make it even simpler (since I want line number and
filename in the log). The user doesn't have to worry about
locking, for example, or generating log headers or timestamps,
or the level of logging which is active for his subsystem.
Seriously: a lot depends on context.
I can agree with this statement although I haven't seen any
context where the use of a stream wrapper led to an advantage
but it in all cases it has the inherent disadvantage of
inhibiting the use of functions taking std::ostream
references.
You also shouldn't use std::endl: this manipulator is only
useful if you really need to flush the stream in addition
to going to a new line.
It's the standard way of terminating a line, and should be
used systematically unless you definitly don't want the
flush.
I'd put it exactly the other way around! The only sensible use
of std::endl is when you definitely want to flush.
The question is what should be the default action for the
uninitiated user. I personally mix '\n' and std::endl,
according to context, but I'm not really a beginner in the
question. The default is to flush, if for no other reason than
because if the program crashes, the user can see how far it got.
In all other cases it is misplaced.
In most cases, avoiding std::endl is premature optimization. It
makes life more difficult for the programmer, with no measurable
benefit otherwise.
In fact, this derives immediately from the claimed knowledge
in the first place: you don't know definitely that you want to
flush otherwise you would have used std::endl.
No. You don't know definitely that a flush is too expensive, so
you do it.
If you are even slightly unsure whether a flush is required at
this position, why enforce it?
Why take the risk of not doing it? The only possible negative
effect of a flush is on performance. Otherwise, the more often
you flush, the closer the observable behavior of your code is to
its abstract behavior, so the easier it is to debug. Flushing
at the end of each line is a good compromize for debugging. And
once the code works, if it's fast enough, there's no reason to
change it---you don't remove assert statements unless the
profiler says you have to, do you?
[...]
People who know iostream's well do vary between '\n' and
std::endl, depending on circomstances---I myself will use '\n'
when outputting a series of lines in a block, with just one
std::endl at the end. But for most people, just using std::endl
is the preferred situation by far.
Given the fact that most people I have encountered don't know
what std::endl really does and normally assume some magic like
inserting end of lines in a system dependent fashion but often
fail to realize that it flushes the stream I'd say that most
people should stay well clear of std::endl! Use std::flush if
you want a flush, use "\n" or '\n' if you want a newline.
std::endl is plain ill-advised.
I'd say that people who don't know iostream's enough to know
what endl does are typically the people who need the implicit
flush. They're the ones who are unaware of the effects of
buffering, and when the program crashes, don't realize that it
might have gotten further than the output would indicate.
There are normally two cases:
- You definitely want to flush your stream to make sure the
data is written as soon as possible. In this case you would
set unitbuf on your stream and there is no need to use
std::endl.
Unitbuf is overdoing it for most streams. (I definitly
don't want it for a log file, for example.)
Most logging facilities I have encountered use an auxiliary
object to do appropriate locking for use in multi-threaded
contexts anyway.
Agreed. An ostream wrapper. :-)
This auxiliary object also defines when a flush is appropriate
and any flush prior to its destruction is ignored anyway.
So you don't use a normal ostream after all :-).
unitbuf is good for ad hoc debugging, however, possibly
highlighting the exact subexpression of some output which
causes the crash.
Unitbuf is too slow to leave in production code. For most
applications, using std::endl isn't.
[...]
Historically, C had three options: unbuffered, line buffered
and fully buffered. Using std::endl corresponds to line
buffered,
Except that it doesn't! If a user fails to use std::endl
(which even would be a deliberate choice e.g. for me) the
stream is not line buffered at all!
Agreed. But of course, since the convention is to use std::endl,
that's what we do; we have line buffering that we can turn off
on a statement by statement basis.
If I want line buffering as the C streams have it, I need to
encapsulate that logic into a corresponding stream buffer,
possibly combined with the use of unitbuf to avoid virtual
calls for each and every character.
You need the virtual function call for every character.
Otherwise, you don't get line buffering when you do something
like:
s << "doh\ndoh\n" ;
Obviously, flushing this stream buffer would be a no op if it
didn't receive a newline character recently.
Calling sync() on a stream buffer should only be a no-op if
nothing has been written to the stream since the last
synchronization (explicitly provoked or otherwise). The
post-condition of sync() is that the output data is synchronized
with the OS; any implementation must meed this post-condition.
which is generally a good compromise for general purpose work.
If you're writing large text files rapidly, of course, you may
want to optimize, and replace std::endl with '\n'.
... and if you don't know whether your code is possibly used for
writing large text files rapidly, you should not pessimise it by
distributing by sprinkling it with explicit flushes!
I'm rather against pre-mature optimization. There's always time
to speed it up later, if it turns out to be necessary. If
you're writing a general purpose library, there may be
exceptions to this, but in application software, never.
Maybe the code I have been working on in the past is rather
unusual but I find myself using streams for some kind of
logging in which case the flushing is implicit in somewhere or
I simply don't know up front what the stream I get passed is
really used for. In neither case I have a desire or a need to
flush the stream explicitly or, going with the rule above,
there is no requirement to insert a flush and thus I don't
insert it!
In full scale applications, about the only use of output streams
that I have is logging, which uses a wrapper, so it doesn't
matter whether you use endl or '\n'. (I can't use ostream's for
application data, because that needs to be fully synchronized,
and ostream has no support for that.) On the other hand, I have
a lot of little helper applications, and they make extensive use
of ostream. And they use std::endl for the most part, because
they're just that, small, helper applications, which don't deal
with a large amount of data. It was easier to develop them
using std::endl, since any time the program crashed, I pretty
much knew how far it had gotten, or what data set was making it
crash. And since their performance is adequate, I'm not about
to go back and "fix" it.
But it's an optimization, to be applied when needed (and
only when you really know what you are doing).
What can go wrong by omitting flushes?
The data doesn't get to the OS.
[...]
For day to day work. I'd say I use it about 90% of the
time.
For what benefit?
For ease of development. When the program crashes (and that
happens), I know exactly the last line processed. Nine times
out of ten, that's enough to know where I was in the input,
which in turn gives me the data set which provoked the crash.
Usually, knowing the data set which provoked the crash, a very
quick code review will show where the error is. (And of course,
that data set gets added to the test cases.)
Logging facilities almost always flush at the end of the
expression; file streams are positively harmed by the
pointless use of flushing;
I don't consider making development easier pointless. I guess
that's where we differ.
Of course, one of the reasons you might want to wrap a file
is to ensure timely flushes.
If I want to ensure timely flushes for a file, I use a
function returning a suitable object of a type derived from
std::ostream, probably with a function like ref() above.
So you need an object derived from ofstream, and one derived
from ostringstream, and one derived from osyslogstream, etc. Or
you duplicate the functionality of ofstream, etc., in some of
your own code. Either way, it's more work for you, and it's
harder to use.
The destructor would flush the stream as it sees fit. Or I
would use a suitable filtering stream buffer. I wouldn't do
the template dance (although dancing in general is good ;-)
In this case, the template is pretty straight forward. I've
used the technique with Sun CC 4.2, with no problems, so it
can't be too complicated.
--
James Kanze GABI Software
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
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]