Deleting dynamic objects

[gurunath.kadam]

hi all,

Normally, in C++, all dynamically created objects (pointer = new object) are deleted after their use is done to avoid memory leaks. This operation can be carried out in a destructor or special function as well.

I have seen many SystemC (done by some experts) codes where such objects are not deleted. Is that not required in SC? Also now I am attempting to create a vector of pointers to objects. Shall I delete these objects later or does SC take care of this (I think SC can not do that)?

Thank you.

[David Black]

You are correct that SystemC does not automatically delete objects.

The reason many coders ignore destructors for SystemC modules/objects is several fold:

1. sc_object's (which includes sc_module's, sc_port's, sc_signal's, sc_prim_channel's, etc...) are created during elaboration and would not need to be destructed until the end of simulation when typically a SystemC program simply exits. Thus the operating system will mop up for you. For example:
   int sc_main(int argc, char* argv[])
   {
   top_module top_instance("top_instance); //< Construct the design hierarchy aka elaborate
   sc_start(); //< run the simulation
   return 0; //< exit the simulator and allow OS to clean up
   }
   
2. SystemC coders are somewhat lazy and given the above example rationalize it away
   
3. This is how they were taught (sad but true)
   

That stated, it is probably worth noting that this situation may not always be the case, and some SystemC coders do write destructors (e.g. myself).

It should be noted that in a co-simulation environment, the assumption of exiting after simulation may not be true. A vendor simulator might even presume to restart a simulation. Thus I argue it is better to create destructors as good C++ programming habit.

TIP: Use the C++11 std::unique_ptr<T> instead of raw pointers. Assumes you can use this class. For older versions of C++, you might consider std::auto_ptr<T>, which is deprecated as I understand it.

[dakupoto]

From pure C++ point of view, it is just bad practice to use a

'new' and not have a matching 'delete'. A lot of people code

with a 'set of pants' approach and are not very sure when

exactly to invoke delete. So they just hope that the SystemC

kernel take care of this messy issue, and with small examples

it works out fine. But think about what would happen, if, as I

had to recently, to tackle a design with 128 64-bit parallel-in

serial-out shift registers.

Then again, a lot of people use SystemC coming from a

software background, and do not realize that in real hardware

one cannot dynamically create components and then delete

them.

Hope that helps.