Rework logging #22
Rework logging #22
Conversation
|
@panmari : What are your thoughts on this change? Is this rather confusing or does it indeed reduce the overall pollution? Personally, I make use of these log-method quiet often (when debugging code via |
| class MeshTriangle; | ||
| class MeshData; | ||
|
|
||
| class Logger { |
There was a problem hiding this comment.
the final idea is to make this a singleton class. Currently, this is stateless. Later, this class could however store the path to its log file (or even an output stream).
There was a problem hiding this comment.
I like it! Having logging code in one place makes sense to me.
| nb.log(); | ||
| nc.log(); | ||
| } | ||
| Vector3f getNormalA() const { return na; } |
There was a problem hiding this comment.
I guess we could omit these getter-method and simply expose na, nb and nc since there are immutable (marked by const), then again this could produce an inconsistent api. One might assume that are getters. Dunno what makes sense the most. Any suggestions @panmari ?
There was a problem hiding this comment.
Whatever your preferred style is. Be aware that this is more than a getter though: It makes a copy of na.
simplay
force-pushed
the
rework-logging
branch
3 times, most recently
from
c357fdd to
34596c1
Compare
|
|
||
| TEST(Logger, log_ray) { | ||
| Ray ray(new Vector3f(), new Vector3f()); | ||
| Logger().log(ray); |
There was a problem hiding this comment.
To make this better testable, you could split the method into string conversion/actual logging, i.e:
ToString(MeshTriangle&) {
}
template
Log(const Loggable& l) {
std::out << ToString(l);
}
This patch moves all log-methods to a common place. The idea of this patch is to reduce the pollution of classes.