Project

General

Profile

Design #983

Which ostream for verbose/obsolescent log mesgs?

Added by John Abbott over 7 years ago. Updated almost 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Tidying
Start date:
25 Nov 2016
Due date:
% Done:

100%

Estimated time:
1.01 h
Spent time:

Description

Which ostream should be used for log messages produced by "verbose mode" or "obsolescent" warnnings?

Note that example programs which produce output on clog or cerr are considered to have failed by the script which runs them and checks that they worked.


Related issues

Related to CoCoALib - Feature #1036: LogStream: stream for log outputClosed2017-03-29

History

#1 Updated by John Abbott over 7 years ago

The standard ostream clog would be the logical choice for logging messages (on a program that runs inside an xterm, at least).

Apart from the (minor) problem with example programs being flagged as "failing" even if they only write logging messages, there are other minor complications with putting logging messages on clog rather than cout. For instance, redirecting output to a file requires redirecting two channels to the file (if logging messages are meant to appear together with standard output). It is not hard to do, but quite possibly many more people know how to redirect one channel than know how to redirect more than one.

In fact, we could use GlobalManager to say where logging message should go. Perhaps the default should be cout (which is probably easier for novices), but advanced users can choose to send them to cerr or wherever. Also something special may be needed for the GUI (I'm pretty sure output on clog/cerr just vanishes into "the bit bucket").

#2 Updated by John Abbott over 7 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10

I have just made a first impl of a simple way to choose the log stream. It comprises a hidden global variable (which is just a reference to an ostream), and two fns (a getter and a setter).

I notice that the impl is quite independent of GlobalManager; since the global var is just a reference, it does not need any special handling at destruction time. So should the impl actually be placed in its own file? anadvantage would be that the files which need to use just the log-stream do not need to include all the other junk from GlobalManager.H.

As it is not so hard to remove a file in the future, perhaps I'll use a separate file, and see how things work out.

#3 Updated by John Abbott about 7 years ago

  • Related to Feature #1036: LogStream: stream for log output added

#4 Updated by John Abbott about 7 years ago

  • Status changed from In Progress to Closed
  • Assignee set to John Abbott
  • Target version changed from CoCoALib-1.0 to CoCoALib-0.99560
  • % Done changed from 10 to 100

Solved by issue #1036 (which is a duplicate of this issue, but I created it because a search for "LogStream" found no hits).

#5 Updated by John Abbott about 7 years ago

  • Target version changed from CoCoALib-0.99560 to CoCoALib-0.99550 spring 2017

#6 Updated by Anna Maria Bigatti almost 7 years ago

  • Estimated time set to 1.01 h

Also available in: Atom PDF