using function for sc_module name in constructor initialization list

[jroever]

I derived a class from sc_module that handles it's own configuration from an XML node passed to the new module constructor.

 

One of the pieces of information handed down in the XML node is the modules name.

 

 

///Constructor

my_module::my_module

( pugi::xml_node            *node                   ///< xml node pointer

)

: sc_module                 ( node->attribute("name").value() )

, clock                     ( "clock_in" )

, targ_socket               ( "targ_socket" )

, init_socket               ( "init_socket" )

{

  ...

}

 

This will result in the following warning:

 

Warning: (W569) sc_module(const char*), sc_module(const std::string&) have been

deprecated, use sc_module(const sc_module_name&): my_mod

 

In addition the system seems to get confused and complains about already existing hierarchical names ...

 

Using sc_module_name inside the constructor initialization list takes care of the warning but the created name is missing the hierarchy push from "my_module" ...

 

...

: sc_module                 ( sc_module_name(node->attribute("name").value()) )

...

 

I believe this is due to the fact that sc_module_name is not created on the stack and it's destructor is called before the constructors of the other entities (i.e. clock) is called ...

 

What would be the appropriate way to achieve a module name function inside the initialization list constructor?!?

 

Thanks for any pointers!

 

- Jens

 

 

[dakupoto]

Most likely this is more of a C++ issue. One workaround might

be to have a static method, that gets invoked right at start (i.e.,

before constructor of any sc_module is called), reads the XML

file data into a table, and then the constructor(s) of your own

modules get invoked, reading data from this static table. I would

imagine that this static method would get invoked from inside 

int sc_main(..). In this case, the SystemC elaboration scheme

is not disturbed in any way (it cannot complain about messing

up names etc., ) Let us see what the experts say.

[Philipp A Hartmann]

Hi Jens,

 

What would be the appropriate way to achieve a module name function inside the initialization list constructor?!?

 

There is none.

 

According to the 1666-2011 standard (5.2.3), every module (at least in the most derived class) requires an sc_module_name parameter:
 

Every class derived (directly or indirectly) from class sc_module shall have at least one constructor. Every
such constructor shall have one and only one parameter of class sc_module_name but may have further
parameters of classes other than sc_module_name. That parameter is not required to be the first parameter
of the constructor.

 

As you have correctly described, the building of the hierarchy fails when creating the sc_module_name object inside the initialisation list.  This is one of the reasons, the above restriction exists.

 

I won't comment on the strong coupling you introduced between your XML-based "configuration/setup" mechanism and the model(s) itself.  If you want to keep that scheme, you can introduce a static create function and make the constructor protected.  Something like:

 

static
my_module* // or something like std::unique_ptr<my_module>
create( pugi::xml_node node )
{
  return new my_module( node, node->attribute("name").value() );
}

protected:
///Constructor
my_module
( pugi::xml_node            *node                   ///< xml node pointer
, sc_core::sc_module_name   ///< name  (no need to give a parameter name)
)
: // sc_module() <- explicit call not needed
...
{
  ...
}

 

Hope that helps,

  Philipp

[jroever]

Thank you! dakupoto for the quick response - and "danke schoen!" Philip for the elaborate one.

The static function method will create the nice compact and encapsulated coding style that I was looking for. 

 

It was very interesting to look into the inner workings of the sc_module_name methods and I was curious whether this was something that might change at some point ... given the quote from the IEEE spec I assume this will 

stay a permanent requirement - which seems totally acceptable.

 

The strong coupling with XML comes from the desire to build a simulation environment that can be reconfigured without the need to recompile - working great so far

 

Cheers,

Jens