+2  A: 

It's possible by checking the stream's 'identity': if ( &out == &cout ) ....

However, I'm in doubt on the usefullness of this test. If your function can handle any output stream, why bother about what stream it is using?

xtofl
Why? Maybe, to write one thing to a file and a different thing to a terminal. E.g., use escape sequences to colorize output when writing to a terminal. Though it won't work if STDOUT is redirected.
atzz
Thats unlikely to work all the time. You should cast objects to the same type before taking their address (In this case some form of common base stream type).
Martin York
@Martin York: is that the case for single-inheritance trees, too?
xtofl
+1  A: 

I consider changing how you stream based on the object you are streaming to do be a horrible idea that completely ignores the whole point of how the stream objects are intended to work. So, I would create a member class or function which returns an object of a type that handles the stream differently. So, for example, if you wanted to provide a colorized stream, you would call:

std::cout << myclass.colorstreamer << endl;

Edit:

Your proposal for handling streams is a bad idea because you have no clue how other people are going to use your code. It is completely unintuitive for a stream to behave differently depending on what object is doing the streaming. I liken this to having a function which returns a different result depending on who called it rather than dependent on what its arguments are, though I acknowledge that technically the stream is an argument.

As for how to do it this way, one way would be to create a colorstreamer, make this new class a member of myclass and make myclass a member of colorstreamer, then make colorstreamer's stream operator a friend of myclass. I'm more worried about the semantics of calling the function (i.e. using .colorstreamer to control how it streams rather than using the stream itself) than I am about how to implement it. My suggestion for how to implement it is quite possibly a bad way to do it; my C++ is rusty.

Brian
Could you please elaborate a little more on why it is a bad idea and could you be more specific as to how to approach the problem your way?
Jordan
@Jordan: Edited to answer your questions, though I think Martin York's comment on your question (i.e. "The whole point of using streams...") is a better wording for why it is a bad idea.
Brian
+1  A: 

It sounds like what you really want to know is not whether the stream is cout but whether the underlying file descriptor is attached to a terminal? If that is so, you need the underlying file descriptor. Unfortunately, you can't get that from a iostream. If it's possible to use cstdio instead of iostream, then you can. If you do have the file descriptor, determining if you are writing to a terminal is a simple as seeing if tcgetattr() returns -1.

Also, don't let anyone tell you not do implement some functionality that you need because it tarnishes the purity of some leaky abstraction. If you really need different behavior, then do what you need to do to produce that functionality.

frankc