Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C++ (http://www.velocityreviews.com/forums/f39-c.html)
-   -   Re: Disabled out stream (operator overloading problem) (http://www.velocityreviews.com/forums/t284988-re-disabled-out-stream-operator-overloading-problem.html)

Dietmar Kuehl 08-12-2004 12:18 PM

Re: Disabled out stream (operator overloading problem)
 
Martin Magnusson wrote:
> How can I make sure that anything that is sent to a

Disabled_Out_Stream
> is handled by an "empty" << operator?


I don't think you can. IMO, the right approach is to wrap the logic in
more involved formatters with a test for the flags, e.g. something like
this:

sdt::ostream& operator<< (std::ostream& out, whatever const& w)
{
if (std::ostream::sentry kerberos(out))
{
// formatting goes here
}
return out;
}

This is not exactly zero cost but it should be sufficiently small to be
irrelevant. If it is still to involved, I would claim that our only
option is to remove uses of the stream conditionally in the first place
using an appropriate macro.

> #include <iostream>


Note that just this include is insufficient if you want to define a
stream buffer. For portable code you need to include <streambuf> or
one of the headers which defines a derived stream buffer like
<fstream> or <sstream>.

> class Disabled_Stream_Buffer: public std::streambuf
> {
> public:
> Disabled_Stream_Buffer() {}
> };


Why do you want a stream buffer which just fails? You can simply use
'0' and have the sentry of the various output functions handle the
stream state. Admittedly, there were some IOStream implementation
which caused crashes if '0' was used for a stream buffer (e.g. an old
version of libstdc++ crashed when 'endl' was used with a 0 stream
buffer).

> class Disabled_Out_Stream : public std::ostream
> {
> public:
> Disabled_Out_Stream():
> std::ostream( new Disabled_Stream_Buffer )
> {}


You don't seem to have destructor. Thus, the above ctor would cause
a memory like. I would use

Disable_Out_Stream(): std::ios(0), std::ostream(0) {}

anyway.

> std::ostream& operator<< (bool& val ){}


Overloading output operators for classes derived from 'std::ostream'
is always a bad idea: it does not really work. The functions are not
virtual and thus they will not be picked up if you go through a
'std::ostream&', e.g. in function call, anyway. Actually, those
function will even cause only the first output operation to go to
a 'Disable_Out_Stream' as the return of this function is an
'std::ostream' such that the next output will use the normal version
anyway.

Also, even if the function is empty, you still need a return statement:

std::ostream& operator<< (bool&) { return *this; }

Personally, I have never encountered a situation where it was
acceptable to evaluate the parameters but not to have the output
operator check the stream buffer. Thus, I would recommend to simply
turn of the output stream by setting the steram buffer to '0' or by
setting one of the state flags. The latter has, however, the danger
that the flags are somewhere accidentally cleared. It is much more
unlikely that the stream buffer is explicitly set.
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting



All times are GMT. The time now is 01:19 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.