From d1b60704e8607070086e4c23314badc624ce1a86 Mon Sep 17 00:00:00 2001 From: Boris Kolpackov Date: Tue, 14 Apr 2015 15:38:25 +0200 Subject: Next iteration on diagnostics --- brep/module.cxx | 37 ++++++++++++++++++++++++++++++------- 1 file changed, 30 insertions(+), 7 deletions(-) (limited to 'brep/module.cxx') diff --git a/brep/module.cxx b/brep/module.cxx index 31e5f99..fb33e1e 100644 --- a/brep/module.cxx +++ b/brep/module.cxx @@ -47,13 +47,7 @@ namespace brep } module:: - module () - : error (severity::error, log_writer_), - warn (severity::warn, log_writer_), - info (severity::info, log_writer_), - log_writer_ (bind (&module::write, this, _1)) - { - } + module (): log_writer_ (bind (&module::write, this, _1)) {} void module:: log_write (diag_data&& d) const @@ -63,5 +57,34 @@ namespace brep //@@ Cast log_ to apache::log and write the records. // + + //@@ __PRETTY_FUNCTION__ contains a lot of fluff that we probably + // don't want in the logs (like return value and argument list; + // though the argument list would distinguish between several + // overloads). If that's the case, then this is probably the + // best place to process the name and convert something like: + // + // void module::handle(request, response) + // + // To just: + // + // module::handle + // + // Note to someone who is going to implement this: searching for a + // space to determine the end of the return type may not work if + // the return type is, say, a template id or a pointer to function + // type. It seems a more robust approach would be to scan backwards + // until we find the first ')' -- this got to be the end of the + // function argument list. Now we continue scanning backwards keeping + // track of the ')' vs '(' balance (arguments can also be of pointer + // to function type). Once we see an unbalanced '(', then we know this + // is the beginning of the argument list. Everything between it and + // the preceding space is the qualified function name. Good luck ;-). + // + // If we also use the name in handle() above (e.g., to return to + // the user as part of 505), then we should do it there as well + // (in which case factoring this functionality into a separate + // function seem to make a lot of sense). + // } } -- cgit v1.1