simplify clumsy usage of DebugTools
|Status:||In Progress||Start date:||10/18/2014|
|Target version:||Robotics Service Bus - rsb-1.0|
Using backtrace functions requires a DebugTools object. Why did you choose for this rather clumsy design?
rsc::debug::DebugToolsPtr dbg = rsc::debug::DebugTools::newInstance();
cout << dbg->formatBacktrace(dbg->createBacktrace());
I suggest the following function-based usage:
cout << rsc::debug::formatBacktrace(rsc::debug::createBacktrace());
Having an overloaded convenience function, this can further simplify to:
cout << rsc::debug::formatBacktrace();
As there are no data elements, there is no need for an DebugTools object, isn't it?
#1 Updated by R. Haschke over 6 years ago
- Status changed from Feedback to Resolved
- Assignee changed from J. Wienke to R. Haschke
- % Done changed from 0 to 90
#2 Updated by J. Wienke over 6 years ago
- Category set to Debug Tools
- Status changed from Resolved to In Progress
This issue cannot be resolved as long as things aren't in the master branch. ;)
Thanks for the work. I am fine with the general API changes, however, there are several formal issues that need to be resolved before we can integrate this into master.
- Your feature branch is based on the URI feature branch. It needs to be rebased on master without the URI changes. If you rename it to
enhancement-2063, it will also automatically the jenkins merge simulator jobs so that you can get feedback from jenkins on your changes (assuming there is no new bug in jenkins for this feature).
- Please do not use inline functions defined in the headers. These end up being compiled in the client programs and not in the library. Hence, internal changes to RSC will require a recompilation of client code, which effectively increases coupling and breaks separation of concerns.
- Please document under which assumptions the demangle functions works (e.g. compiler). Any chance to get the code more readable? E.g. by using real c++ strings.
- I am note sure whether we can simply include the
StackWalkeras it is to not violate license agreements. We need to find this out.
- In any case, the windows code needs to adhere to our coding standards. In all 3 windows-related files, tabs and windows line ends are used, our license headers are missing and indentation and line break rules are off.
- Please either integrate the required features of
MyStackWalkerdirectly into the original
StackWalkerand limit its functionality to what we actually require or give this class a more descriptive name to explain the purpose why it exists. Adapting the
StackWalkerto the functionality we need, might also be sufficient to move it further apart from the original code base so that we declare this as our own code under our license. I am not sure about this.
Apart from the general licensing issue, would you adapt your branch accordingly?
#4 Updated by J. Wienke over 6 years ago
Robert Haschke wrote:
I can work on that some time.
I suggest to keep the StackWalker code as is. I didn't touched anything there yet and I don't want to.
So, I'd propose to move the windows stracktrace support to a new issue and feature branch so that we can continue with the API changes without having to discuss the license issues. Moreover, this also feels more like a separate feature.
#5 Updated by R. Haschke over 6 years ago
I worked on all the points you pointed out. However, I didn't touched StackWalker itself.
You should decide how to deal with the BSD license of that code or extract the neccessary functionality. Actually StackWalker is much more powerful than required in rsc context: It can create stacktraces of different threads or even processes.