Re: Creating custom debug streams

[Ingo Ruhnke]

David Philippi <address@hidden> writes:

> Trace is usually used for very detailed debug messages, e.g. when
> you're searching for an error in a particular section of code. This
> way you can normally activate debugging and if you've encountered a
> bug you activate trace to find it.
 
Speaking about very detailed debug messages, the current aproach does
not allow to simply set a #define and disable all the output, so
extremly detailed output (say something in Pingus::update()) could be
quite a performance hit. Disabling it inside MultiplexStream wouldn't
really solve that, since the formating of numbers, etc. is still done.
So one might use another aproach for that or include all "ptrace <<"
stuff into a #define, but I am not sure that we really need that, in
case one is debugging an action, one can easly add the stuff he needs
into a std::cout and remove that when he is done.

>>>   - profiling
>> pprof
>
> Is there interest in profiling Pingus yet?
 
Maybe, there are currently a few performance holes, which one should
be able to find and fix without much profiling, since they are in the
overall structure. An example is the resource and level loading code,
it would make sense to reuse the maptiles when replaying a level,
instead of generation them newly. The memory allocation is also not
that clean. Some points for freeing unused resources would also be
usefull, but the current resource loading structure doesn't allow that
(no refcounting, etc.).

>>>   - component specific
>> We could flag them for the components:
>> pwarn(PINGUS_SOUND) << ...
>> pwarn(PINGUS_DISPLAY) << ...
> 
> How would you implement this? operator ()?

Yep.

> BTW you just violated your own design rules.

I know.

> In the naming convention it's stated that every class shall have
> it's own file.

I am not that strict with that one and with all the others, if a class
makes only sense in connection with another class, I place them in a
single file.

> I mention this because I don't approve of MultiplexStream and
> MultiplexStreamBuffer beeing in the same file. What do you think
> about changing MultiplexStreamBuffer into a private subclass Buffer
> of MultiplexStream?

That gives IIRC some problem with some documentation tools, but I am
not sure if its an issue with doxygen.

> Using MultiplexStreamBuffer direct makes no sense anyway and the
> readability of the code would probably improve quite a bit... If you
> agree I'll do the change myself.

I did place a little bit too much functionality directoly into
MultiplexStream, it would probally be better to split the whole thing
into some more classes, so that one can inherit from
MultiplexStreamBuffer (or some other class) and add the prefix and
multiplex functionality himself. The complete MultiplexStreamBuffer
class is mostly copy&paste from ConsoleBuffer, so adding a parent
class would make sense.

-- 
Advent:     http://www.freesoftware.fsf.org/advent/
Feuerkraft: http://www.freesoftware.fsf.org/feuerkraft/
Pingus:     http://pingus.seul.org/           || ICQ:      59461927
Home:       http://pingus.seul.org/~grumbel/  || JabberID: address@hidden