Re: Verbosity Control

Bishnupriya,

some comments on the open issues below.

On 03/12/10 19:28, Bishnupriya Bhattacharya wrote:
>
> 2) sc_module::sc_report, sc_core::sc_report
>
> [ooops! My prototype had the name as report() - since report() is very likely to clash with an user-defined method name, I tagged it with a sc_, and ended up duplicating. Another name has to be chosen for sure like what you propose or sc_gen_report()]

I like sc_gen_report()!

> 3) SC_REPORT_XXX_V
>
> Bishnupriya says:
> "the macros expand to invoke the function sc_report(); if the macros
> are invoked from global scope, sc_report() will resolve to the
> global function, and if invoked from module scope, sc_report() will
> resolve to the module's sc_report() function;"
>
> I don't like this macro definition to perform an unqualified call to
> sc_report(). This won't work on the global scope, if the user only
> includes <systemc> (which is recommended, I guess). Secondly, it
> will resolve to the wrong function, if sc_module is inherited
> indirectly from a templated base class (sice sc_report is not a
> dependent name).
>
> [I myself had this technical concern for the global case when user includes <systemc>, but could not reproduce it with my prototype - not sure why. The sc_module derived case had never occurred to me.]

You're right. Long live C++'s argument dependent lookup ...
The first parameter is sc_core::sc_severity, so the namespace sc_core is
automatically added to the considered namespaces. I've missed this before.

This covers my first issue. For the issue wrt dependent names, the
following scenario is causing the problem:

  template< int BUSWIDTH >
  SC_MODULE(slave_base) {};

  template< int BUSWIDTH >
  struct slave : slave_base<BUSWIDTH>
  {
    SC_CTOR(slave) {
      sc_gen_report( ... ); // calls sc_core::sc_gen_report
    }
  };

The user has to qualify the function call (e.g. with this->) to be
dependent on a template parameter for a (modern) compiler to decide that
it shall defer the looked until instantiation.

But: If we make the actual values of SC_REPORT_XXX_V to be a plain
sc_gen_report( ... ), we can actually qualify the macro call itself:

  this->SC_REPORT_INFO_V( ... );

(Do we need a note for this?)

So, on second thought, everything seems to be fine as it has been
proposed by you.

> do you see any technical disadvantage in including the reporting related member methods for sc_module?

No. Not anymore. I should have tried this with a compiler, before
raising unsubstantiated concerns off the top of my head.

> namespace sc_core {
> void
> sc_gen_report( sc_severity severity,
> const char* msg_type,
> const char* msg,
> int verbosity,
> const char* file = NULL,
> int line = 0 );
> }
>
> where file and line are optional for convenience.

Any thoughts on the default arguments for file and line?
In many cases, the actual cause for the report lies somewhere else,
unrelated to the position of the report statement.

If we allow 'file' to be NULL (and line as well), the what() of
sc_report could omit this information. Luckily, both values can never
occur with __FILE__, __LINE__.

Greetings from Oldenburg,
  Philipp

-- 
Philipp A. Hartmann
Hardware/Software Design Methodology Group
OFFIS Institute for Information Technology
R&D Division Transportation · FuE-Bereich Verkehr
Escherweg 2 · 26121 Oldenburg · Germany · http://www.offis.de/
Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · Skype: phi.har
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.