bc87fa30d7
This was somewhat tricky because the RefCnt API was somewhat odd. The biggest confusion was that the the RefCnt object's constructor that took a TYPE& cloned the object. I created an explicit virtual clone() function for things that took advantage of this version of the constructor. I was conservative and used clone() when I was in doubt of whether or not it was necessary. I still think that there are probably too many instances of clone(), but hopefully not too many. I converted several instances of const MsgPtr & to a simple MsgPtr. If the function wants to avoid the overhead of creating another reference, then it should just use a regular pointer instead of a ref counting ptr. There were a couple of instances where refcounted objects were created on the stack. This seems pretty dangerous since if you ever accidentally make a reference to that object with a ref counting pointer, bad things are bound to happen. |
||
|---|---|---|
| .. | ||
| AbstractCacheEntry.cc | ||
| AbstractCacheEntry.hh | ||
| AbstractController.hh | ||
| AbstractEntry.cc | ||
| AbstractEntry.hh | ||
| AbstractProtocol.hh | ||
| Controller.py | ||
| Message.hh | ||
| NetworkMessage.hh | ||
| RubySlicc_ComponentMapping.cc | ||
| RubySlicc_ComponentMapping.hh | ||
| RubySlicc_includes.hh | ||
| RubySlicc_Profiler_interface.cc | ||
| RubySlicc_Profiler_interface.hh | ||
| RubySlicc_Util.hh | ||
| SConscript | ||