tags:

views:

562

answers:

4

I'm trying to implement my own QDebug() style debug-output stream, this is basically what I have so far:

struct debug
{
#if defined(DEBUG)
    template<typename T>
    std::ostream& operator<<(T const& a) const
    {
        std::cout << a;
        return std::cout;
    }
#else
    template<typename T>
    debug const& operator<<(T const&) const
    {
        return *this;
    }

    /* must handle manipulators (endl) separately:
     * manipulators are functions that take a stream& as argument and return a
     * stream&
     */
    debug const& operator<<(std::ostream& (*manip)(std::ostream&)) const
    {
        // do nothing with the manipulator
        return *this;
    }
#endif
};

Typical usage:

debug() << "stuff" << "more stuff" << std::endl;

But I'd like not to have to add std::endl;

My question is basically, how can I tell when the return type of operator<< isn't going to be used by another operator<< (and so append endl)?

The only way I can think of to achieve anything like this would be to create a list of things to print with associated with each temporary object created by debug(), then to print everything, along with trailing newline (and I could do clever things like inserting spaces) in ~debug(), but obviously this is not ideal since I don't have a guarantee that the temporary object is going to be destroyed until the end of the scope (or do I?).

A: 

The stream insertion (<<) and extraction (>>) are supposed to be non-members.

My question is basically, how can I tell when the return type of operator<< isn't going to be used by another operator<< (and so append endl)?

You cannot. Create a member function to specially append this or append an endl once those chained calls are done with. Document your class well so that the clients know how to use it. That's your best bet.

dirkgently
I'm going to be the main user of this; I'm trying to save writing std::endl over and over and over again.
Autopulated
`endl` does two things -- 1) add a newline -- which is something you cannot control since strings can have embedded newlines and 2) flushes the output stream -- which you can control without needing to put them in the dtor. Your question wasn't very clear what you are trying to achieve.
dirkgently
+2  A: 

When you write that this is the typical usage:

debug() << "stuff" << "more stuff" << std::endl;

are you definitely planning to construct a debug object each time you use it? If so, you should be able to get the behavior you want by having the debug destructor add the newline:

~debug()
{
    *this << std::endl;

    ... the rest of your destructor ...
}

That does mean you cannot do something like this:

// this won't output "line1" and "line2" on separate lines
debug d;
d << "line1";
d << "line2";
R Samuel Klatchko
@last part: Will work if you surround it with braces. When the debug object goes out of scope, its destructor is called.
jmucchiello
@jmucchiello: The destructor will be called at the end of the statement, which is exactly when you want the newline to be inserted.
Ben
@jmucchiello - what I mean by "won't work" is that line1 and line2 will not be on separate lines like they would have been if you wrote `debug() << "line1"; debug() << "line2()";`
R Samuel Klatchko
Yes, I'm definitely planning to do that, I will probably disable the copy / copy assignment constructors to somewhat enforce it.
Autopulated
+3  A: 

Something like this will do:

struct debug {
    debug() {
    }

    ~debug() {
        std::cerr << m_SS.str() << std::endl;
    }

public:
    // accepts just about anything
    template<class T>
    debug &operator<<(const T &x) {
        m_SS << x;
        return *this;
    }
private:
    std::ostringstream m_SS;
};

Which should let you do things like this:

debug() << "hello world";

I've used a pattern like this combined with a lock to provide a stream like logging system which can guarantee that log entries are written atomically.

NOTE: untested code, but should work :-)

Evan Teran
You have a mistake: the destructor should be called "debug".Also, why use the intermediate ostringstream? Can't you just output things to cerr as they arrive in your operator<<?
Manuel
I fixed the destructor name (copy/paste error). but the stringstream has a purpose. It makes it so the output is not written out until the destructor is called (making it possible to prevent threading issues).
Evan Teran
+2  A: 

Qt uses a method similar to @Evan. See a version of qdebug.h for the implementation details, but they stream everything to an underlying text stream, and then flush the stream and an end-line on destruction of the temporary QDebug object returned by qDebug().

Bill
Cool thanks, that's what I wondered, and confirms that the temporary gets promptly destructed most of the time :)
Autopulated
@Autopulated: I forget the precise verbiage, but I believe that the standard mandates that an unnamed object gets destructed immediately after the expression that it was created in.
Evan Teran
Aha! found it: 12.2/4 says "There are two contexts in which temporaries are destroyed at a different point than the end of the full expression." Which basically means that aside from the two exceptions about to be listed, temporary objects will be destroyed immediately at the end of the expression.
Evan Teran
Cool thanks!That's the confirmation I was looking for.
Autopulated