#include <google/cloud/log.h>
Definition at line 233 of file log.h.
◆ LogSink()
google::cloud::v0::LogSink::LogSink |
( |
| ) |
|
◆ AddBackend()
long google::cloud::v0::LogSink::AddBackend |
( |
std::shared_ptr< LogBackend > |
backend | ) |
|
◆ BackendCount()
std::size_t google::cloud::v0::LogSink::BackendCount |
( |
| ) |
const |
◆ ClearBackends()
void google::cloud::v0::LogSink::ClearBackends |
( |
| ) |
|
◆ CompileTimeEnabled()
static constexpr bool google::cloud::v0::LogSink::CompileTimeEnabled |
( |
Severity |
level | ) |
|
|
inlinestatic |
Return true if the severity is enabled at compile time.
Definition at line 238 of file log.h.
◆ DisableStdClog()
static void google::cloud::v0::LogSink::DisableStdClog |
( |
| ) |
|
|
inlinestatic |
◆ empty()
bool google::cloud::v0::LogSink::empty |
( |
| ) |
const |
|
inline |
Return true if this object has no backends.
We want to avoid synchronization overhead when checking if a log message is enabled. Most of the time, most messages will be disabled, so incurring the locking overhead on each message would be too expensive and would discourage developers from creating logs. Furthermore, missing a few messages while the change of state "propagates" to other threads does not affect the correctness of the program.
Note that memory_order_relaxed
does not provide a compiler barrier either, so in theory stores into the atomic could be reordered by the optimizer. We have no reason to worry about that because all the writes are done inside a critical section protected by a mutex. The compiler cannot (or should not) reorder operations around those.
Definition at line 263 of file log.h.
◆ EnableStdClog()
static void google::cloud::v0::LogSink::EnableStdClog |
( |
| ) |
|
|
inlinestatic |
◆ Instance()
LogSink & google::cloud::v0::LogSink::Instance |
( |
| ) |
|
|
static |
Return the singleton instance for this application.
Definition at line 47 of file log.cc.
◆ is_enabled()
bool google::cloud::v0::LogSink::is_enabled |
( |
Severity |
severity | ) |
const |
|
inline |
Return true if severity
is enabled.
We want to avoid synchronization overhead when checking if a log message is enabled. Most of the time, most messages will be disabled, so incurring the locking overhead on each message would be too expensive and would discourage developers from creating logs. Furthermore, missing a few messages while the change of state "propagates" to other threads does not affect the correctness of the program.
Note that memory_order_relaxed
does not provide a compiler barrier either, so in theory stores into the atomic could be reordered by the optimizer. We have no reason to worry about that because all the writes are done inside a critical section protected by a mutex. The compiler cannot (or should not) reorder operations around those.
Definition at line 281 of file log.h.
◆ Log()
void google::cloud::v0::LogSink::Log |
( |
LogRecord |
log_record | ) |
|
◆ minimum_severity()
Severity google::cloud::v0::LogSink::minimum_severity |
( |
| ) |
const |
|
inline |
◆ RemoveBackend()
void google::cloud::v0::LogSink::RemoveBackend |
( |
long |
id | ) |
|
◆ set_minimum_severity()
void google::cloud::v0::LogSink::set_minimum_severity |
( |
Severity |
minimum | ) |
|
|
inline |