This removes the following Boost constructs:
- boost::shared_ptr, boost::weak_ptr
- boost::enable_shared_from_this
- boost::static_pointer_cast, boost::dynamic_pointer_cast
The appropriate includes were also removed. All C++11 versions of these
require #include <memory>.
Note that the stdlib and Boost versions have the exact same syntax, they
only differ in the namespace (boost vs. std). The modifications were all
done using sed, with the exception of boost::scoped_ptr, which was
replaced by std::unique_ptr.
References to boost::smart_ptr were also removed.
boost::intrusive_ptr is not removed in this commit, since it does not
have a 1:1 mapping to a C++11 construct.
Added cmake variable to set the component (currently UHD or MPM).
so the banner printed by the log_resource would reference the correct
component. Added accessor function and appropriate calls in log.cpp.
Signed-off-by: michael-west <michael.west@ettus.com>
The first log message of UHD is always something like this:
[INFO] [UHD] linux; GNU C++ version [...]
However, it was being printed regardless of the requested log level.
This will disable all initial log messages if the requested log level is
greater than INFO.
The colour codes used for console logging were incorrectly defined.
Some colours would simply not rendered this way (e.g., red), others
had the boldness flag wrong.
In log.cpp, a deadlock can occur while popping elements from the log
queue. If the queue is empty, the call does not timeout, and waits
infinitely. Replacing pop_with_wait() with pop_with_timed_wait() solves
this issue.
- Fixes: cmake -DUHD_LOG_FILE wasn't respected
- Fixes: UHD_LOG_FILE and UHD_FILE_LOG_LEVEL had to both be set for
either to take effect
- Fixes: Use of unnecessary boost::make_shared<>
- Also factored out setting up console- and file logger into their own
locations in an attempt to improve readability
Empty log messages are now skipped for faster processing. The
'terminating' log message is now also empty (and thus skipped).
Reviewed-by: Brent Stapleton <brent.stapleton@ettus.com>
This means it's very unlikely that logging messages get dropped, but the
downside is that LOG macros can block for up to 250 ms. This is very
unlikely though.
Note that fastpath logging does not have this feature. It's always fast,
and might drop messages.
- allows adding new loggers by using add_logger API call
- existing loggers (console, file) can be disabled easily
- number of logging sinks is not limited
Signed-off-by: Martin Braun <martin.braun@ettus.com>
The implementations now contain the string stream in each instance.
This way there is not a global stringstream to lock access to.
This resolves the issue of nested log calls locking condition.
