Re: Creating custom debug streams

[David Philippi]

On Thursday 06 June 2002 13:41, Ingo Ruhnke wrote:

> >> We could flag them for the components:
> > How would you implement this? operator ()?
> Yep.

Shouldn't be that hard to implement, more a matter of time. Do you have some 
concrete ideas how you want it done?

1. One could define operator (const char *) this would allow arbitrary   
   modules, but also typos and make it more difficult to filter the channels.

2. operator (int) combined with an enum { PINGUS_SOUND = 1, PINGUS_DISPLAY = 
   2, PINGUS_X = 3, ... } this would prevent typos and one could add a
   corresponding flag to each case stating wheter it should be displayed.

> 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.

If they have at least more different names it's easier to read.

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

Are you saying that you'd not use a usefull feature because it makes problems 
with a documentation tool?
Anyway, I can't imagine that doxygen doesn't support such an elementary 
feature as inner classes and in the worst case we have to include the 
documentation in another way. Doxygen has quite a lof of functions designed 
to allow the inclusion of external documentation.
So if you don't cry out I'm going to change it, I've added a set_prefix () 
and removed unneccessary code already and plan to add filter flags and 
operator ().

> 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. 

Well, I don't think that there's too much functionality, in fact I'm planning 
to include some more. ;-)
MultiplexStream has nearly none in fact, most is in MultiplexStreamBuffer. 
I'd propose to rename MultiplexStream to DebugStream and include all 
necessary functionality to use it as a debugging system.

> The complete MultiplexStreamBuffer
> class is mostly copy&paste from ConsoleBuffer, so adding a parent
> class would make sense.

That explains a few things. I was wondering why three of six member variables 
where not used at all...
On the other hand, a bit documentation about overflow () would be usefull, I 
can't say that I understand what this method does or who calls it. A 
reference to documentation about streambuf would be enough I think.

Bye David