using ostream as function argument - c++

Question

I have a basic problem with understanding what ostream is exactly. I know that it's a base class for the output stream, but I can't quite gasp when to use it and why to use it instead of just saying std::cout.
So here I have this example where I have to create a new class named stack with a pop() function (just as in the class already provided by C++).
Here list_node is a struct which consists of two elements: the key (which is an integer) and an interator which points to the next integer.
Definition of list_node (already given):
struct list_node {
int key;
list_node∗ next;
// constructor
list_node (int k, list_node∗ n)
: key (k), next (n) {}
};
and here is the definition of the class (already given as well):
class stack {
public:
void push (int value) {...}
...
private:
list_node∗ top_node;
};
and here's the part with which I'm having trouble with:
void print (std::ostream& o) const
{
const list_node* p = top_node;
while (p != 0) {
o << p->key << " "; // 1 5 6
p = p->next;
}
}
I don't understand why they are using ostream& o as function argument. Couldn't they've just taken the top_node as argument and used as well .next function on it (.next reads the next list_node) and then they could've just printed it with the std::cout function. Why is it better to do it the way they did?

Answer 1

Why is it better to do it the way they did?
I am not sure of your question, and not sure it is a better way.
Perhaps the intent was for flexibility. Here is an example from my app library:
When I declare a data attribute as an ostream
class T431_t
{
// ...
std::ostream* m_so;
// ...
I can trivially use that attribute to deliver a report to 'where-m_so-points'. In this app, there are several examples of *mso << ... being used. Here is the primary example.
inline void reportProgress()
{
// ...
*m_so << " m_blk = " << m_blk
<< " m_N = 0x" << std::setfill('0') << std::hex << std::setw(16) << m_N
<< " " << std::dec << std::setfill(' ') << std::setw(3) << durationSec
<< "." << std::dec << std::setfill('0') << std::setw(3) << durationMSec
<< " sec (" << std::dec << std::setfill(' ') << std::setw(14)
<< digiComma(m_N) << ")" << std::endl;
// ...
}
Note that in the class constructor (ctor), there is a default assignment for m_so to std::cout.
T431_t(uint64_t maxDuration = MaxSingleCoreMS) :
// ..
m_so (&std::cout), // ctor init - default
// ..
{
// ...
When the user selects the dual-thread processing option, which is a command line option to perform the app in about 1/2 the time by using both processors of my desktop, the reports can become hard to read if I allow the two independent output streams to intertwine (on the user screen). Thus, in the object instance being run by thread 2, m_so is set some something different.
The following data attribute captures and holds thread 2 output for later streaming to std::cout.
std::stringstream m_ssMagic; // dual threads use separate out streams
Thread 2 is launched and the thread sets it's private m_so:
void exec2b () // thread 2 entry
{
m_now = Clock_t::now();
m_so = &m_ssMagic; // m_so points to m_ssMagic
// ...
m_ssMagic << " execDuration = " << m_ssDuration.str()
<< " (b) " << std::endl;
} // exec2b (void)
While thread 1 uses std::cout, and thread 2 uses m_ssMagic, 'main' (thread 0) simply waits for the joins.
The join's coordinate the thread completion, typically about the same time. Main (thread 0) then cout's the m_ssMagic contents.
//...
// main thread context:
case 2: // one parameter: 2 threads each runs 1/2 of tests
{ // use two new instances
T431_t t431a(MaxDualCoreMS); // lower test sequence
T431_t t431b(MaxDualCoreMS); // upper test sequence
// 2 additional threads started here
std::thread tA (&T431_t::exec2a, &t431a);
std::thread tB (&T431_t::exec2b, &t431b);
// 2 join's - thread main (0) waits for each to complete
tA.join();
tB.join();
// tA outputs directly to std::cout
// tB captured output to T431_t::m_ssMagic.
// both thread 1 and 2 have completed, so ok to:
std::cout << t431b.ssMagicShow() << std::endl;
retVal = 0;
} break;
To be complete, here is
std::string ssMagicShow() { return (m_ssMagic.str()); }
Summary
I wrote the single thread application first. After getting that working, I searched for a 'simple' way to make use of the second core on my desktop.
As part of my first refactor, I a) added "std::ostream m_so" initialized to &std::cout, and b) found all uses of std::cout. Most of these I simply replaced with "*m_so". I then c) confirmed that I had not broken the single thread solution. Quite easy, and worked the first try.
Subsequent effort implemented the command line 'dual-thread' option.
I think this approach will apply to my next desktop, when budget allows.
And from an OOP standpoint, this effort works because std::ostream is in the class hierarchy of both std::cout and std::stringstream. Thus
"std::cout is-a std::ostream",
and
"std::stringstream is-a std::ostream".
So m_so can point to instance of either derived class, and provide virtual method 'ostream-access' to either destination.