Comments on: ScopeLogger

By: rmn

rmn — Sat, 13 Mar 2010 10:40:31 +0000

Essentially, that’s what it is. It would work the same when used within member functions (even through LOG_FUNC).

We could add a sort of a LOG_MEMFUN macro, so it would print the ‘this’ pointer as well, perhaps?

By: shebang

shebang — Fri, 05 Mar 2010 23:46:44 +0000

It could be interesting to implement the same scopelogger for tracing objects instead of functions

By: lprichmond

lprichmond — Fri, 08 Jan 2010 19:42:47 +0000

Vladimir Prus has just volunteered be the review manager for the Boost.Log review. So one step closer.

By: lorg

lorg — Sun, 06 Dec 2009 23:32:14 +0000

Very nice code.
I’d say that the exit point is also important – you can log stuff about the return value of the function, maybe special case bools, ints and pointers.
Also interesting is the addition of MT support.

On another subject:
In Python it’s a “standard exercise” to implement a trace function decorator. With little additional work, such a decorator can work & look just like your LOG_FUNC, except maybe making it a little more Pythonic.

By: rmn

rmn — Wed, 02 Dec 2009 21:12:52 +0000

Very nifty feature of VS, thanks for introducing it.
You are essentially correct with your observation that this will probably be for light debugging purposes, or maybe statistical analysis of execution (for example, we could also create a timer and print its stats on return, to have the timing of each function).
This approach is also pretty useful since it does not have to be an entirely compile time mechanism – we can set at least some of these printouts to be run-time dependant (perhaps printing only if the function took longer than it should have, or depending on environment setup, etc).
I ofcourse agree that if hardcore debug is necessary, we’ll probably have to invoke more complex and sophisticated tools (be it gdb, totalview, VS debugger, ..).

By: Ofek Shilon

Ofek Shilon — Wed, 25 Nov 2009 07:15:18 +0000

If we skip the point-of-exit tracing, then VS already has something similar, via tracepoints: create a brekpoint, right click and mark ‘when hit..’, then mark ‘print a message’ and specify $CALLSTACK.

Pros: (1) involves intervention only in the lowest function you wish to trace – and not its entire potential callers tree (which can be unknown), (2) doesn’t require re-compilation.
Cons: (1) cannot (AFAIK) route output to a file or anywhere outside the debugger windows, (2) involves an actual breakpoint, with a significant performance penalty if the tracepoint is hit often.

Anyway, seems to me this is mainly a debugging facility: to collect trace info in the field you’d probably want crash dumps and stack walkers and an entirely different mess. So for just debugging, I think trace points might be an easier solution (in particular because you can’t know the full range of potential callers).

By: rmn

rmn — Tue, 24 Nov 2009 21:32:05 +0000

Well, apart from maintaining the correct indentation (decreasing the indent_ member), the destructor doesn’t do much.
In my opinion it just makes it easier to identify call trees if we print where the function actually makes its exit, but we couldv’e spared it just as easily.

Another thing we could use the destructor for is timing the execution time of every function, so we could print the time each function took in the destructor of this ScopeGuard (using something very similar to this).

By: alpmestan

alpmestan — Mon, 23 Nov 2009 07:43:36 +0000

Indeed, but it’s been in the “proposed” state for a long time. I don’t know when it’ll be reviewed and possibly accepted, and even if it’ll be.

By: ofek

ofek — Sun, 22 Nov 2009 19:41:44 +0000

Roman – do you have an actual scenario where the point of leaving a function adds value? (I mean – why should the destructor be instrumented?)

By: ofek

ofek — Sun, 22 Nov 2009 08:50:08 +0000

Nice! As another quibble, I’d suggest branching the LOG_FUNC definition to be null if _DEBUG is not defined. Naturally the overhead of stream outputs can be prohibitively expensive in production builds.