Re: Disabled out stream (operator overloading problem)

Discussion in 'C++' started by Dietmar Kuehl, Aug 12, 2004.

  1. 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::eek:stream& operator<< (std::eek:stream& out, whatever const& w)
    {
    if (std::eek:stream::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::eek:stream
    > {
    > public:
    > Disabled_Out_Stream():
    > std::eek:stream( 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::eek:stream(0) {}

    anyway.

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


    Overloading output operators for classes derived from 'std::eek:stream'
    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::eek:stream&', 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::eek:stream' 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::eek:stream& 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:> <http://www.dietmar-kuehl.de/>
    <http://www.contendix.com> - Software Development & Consulting
     
    Dietmar Kuehl, Aug 12, 2004
    #1
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Martin Magnusson
    Replies:
    0
    Views:
    406
    Martin Magnusson
    Aug 12, 2004
  2. John Smith
    Replies:
    2
    Views:
    447
    Ivan Vecerina
    Oct 6, 2004
  3. mrstephengross
    Replies:
    3
    Views:
    418
    James Kanze
    May 10, 2007
  4. Grey Alien
    Replies:
    4
    Views:
    528
    Jerry Coffin
    Aug 4, 2007
  5. VirGin
    Replies:
    6
    Views:
    677
    James Kanze
    Jan 22, 2008
Loading...

Share This Page