Restore hierarchy helper API to public

[janweinstock]

VCML requires access to hierarchy_curr, hierarchy_pop and hierarchy_push APIs. Please consider making them public again for SystemC 3.0.0.

[barnasc]

These specific member functions were never part of any IEEE 1666 standard and therefore usage should be discouraged. Instead, SystemC 3.0.0 follows IEEE Std. 1666-2023, which now defines a new class called sc_core::sc_hierarchy_scope. This class provides an interface to allow an application to place objects of type sc_core::sc_object in an object hierarchy outside the current hierarchical scope. Please check the LRM for more details on this new API.

[janweinstock]

I am fully aware of sc_hierarchy_scope, but it is an unsuitable replacement for the APIs we used to have. And while these APIs are not defined in the standard, they have been a public API for almost two decades now (at least since SystemC 2.0).

I would understand no longer offering them if they had been removed, but since they are still there, this change just seems to unnecessarily break compatibility for projects that want to support both SystemC 2.3.x and 3.0.0. Why are we doing this?

[barnasc]

Why are we doing this?

The goal is SystemC model portability and enable reuse across different tools/solutions, where a model is not necessarily the model of the end-user only, but also middle-layer and/or infrastructure to compose a model. As hierarchy_curr, hierarchy_pop and hierarchy_push are not part of the IEEE 1666 standard, there is no guarantee that your model will work in a different tool/framemork which adheres to the IEEE SystemC standard.

I would appreciate your feedback why sc_hierarchy_scope is seen as an unsuitable replacement. Do you miss specific technical capabilities and language constructs, or is your concern related to the execution semantics (or both)? It would be good to clarify your concerns wrt the new standardized API, such that we can improve and/or enhance it.

[janweinstock]

It is mainly needed to support vcml::hierarchy_guard, which in theory does the same as sc_hierarchy_scope, but unfortunately, its design appears to be incompatible. Here is a small example:

struct hierarchy_guard {
    hierarchy_guard(sc_module* mod) { hierarchy_push(mod); }
    ~hierarchy_guard() { hierarchy_pop(); }
};

Use case (simplified):

void my_tlm_port::stub() {
    sc_module* parent = get_parent_module_of_my_port();
    vcml::hierarchy_guard guard(parent); // does hierarchy push
    create_stub_and_bind_it_to_my_port(); // creates new objects/modules
}  // does hierarchy pop

[lmailletcontoz]

As discussed in the LWG calls, usage of implementation-specific functions is discouraged in end-user code. You can make a proposal to contribute to the next standardization round if you believe new/updated standard APIs shall be offered.