Rewrite uses of VLOG_IF and LOG_IF.

VLOG_IF's evaluation order is ambiguous - does it mean
`if (cond) VLOG(lvl)` or `if (VLOG_IS_ON(lvl) && cond) LOG(INFO)`?
In particular, the way it works now is inconsistent with the way the
rest of the LOG macros evaluate their arguments.
Fixing this would be hard, and the macro's behavior would still surprise
some people. Replacing it with an if statement is simple, clear, and unambiguous.

Change-Id: I97a92d17a932c0a5344a1bf98d676308793ba877
This commit is contained in:
Sameer Agarwal
2020-10-12 10:07:13 -07:00
parent d1b35ffc16
commit 8bfdb02fb1
8 changed files with 171 additions and 91 deletions
+6 -4
View File
@@ -685,10 +685,12 @@ bool ProblemImpl::Evaluate(const Problem::EvaluateOptions& evaluate_options,
// type of linear solver being used.
evaluator_options.linear_solver_type = SPARSE_NORMAL_CHOLESKY;
#ifdef CERES_NO_THREADS
LOG_IF(WARNING, evaluate_options.num_threads > 1)
<< "No threading support is compiled into this binary; "
<< "only evaluate_options.num_threads = 1 is supported. Switching "
<< "to single threaded mode.";
if (evaluate_options.num_threads > 1) {
LOG(WARNING)
<< "No threading support is compiled into this binary; "
<< "only evaluate_options.num_threads = 1 is supported. Switching "
<< "to single threaded mode.";
}
evaluator_options.num_threads = 1;
#else
evaluator_options.num_threads = evaluate_options.num_threads;