wine/ library/debug.c include/wine/library.h i ...

[Dimitrie O. Paun]

On January 2, 2003 11:22 pm, Alexandre Julliard wrote:
> I'd rather not let users write to the buffer directly. IMO a function
> like debuglvitem_t should be dumping things directly to the output,
> not build a huge string and then print it. The temporary strings
> buffer should be only for really short lived strings.

Well, I've tried the dump-directly-to-output version, and it invariably
leads to ugly code. The usage of debuglvitem_t is _so_ much nicer
compared to anything else. And uniform. And easy to understand.
Granted, the function is a bit big, but the resulting string is not
that 'huge'. In fact, the function is big because I'm trying to minimize
the string (and thus uncluttered the output). The max_size of 200 that we 
have now is more than enough for anything we need. As for the lifetime
of the string, it's _identical_ to the RECT, POINT, and SIZE ones.

> > >         Added inline functions to format POINT, SIZE and RECT
> > > structures.
> >
> > Can we pretty please get shorter names for them in Wine? Like without the
> > wine_ prefix? :)
>
> I'm not sure we want that. I know it's what we have been doing so far,
> but it's very confusing to have to use different debugging functions
> depending on what part of the code you are in. I think we should try
> to move towards a more unified interface.

It depends on how you look at it. We're going to end up with a
mixture of wine_ and non-wine_ stuff that is a lot more confusing and
ugly than what we have now.

On the other hand, cluttering all on Wine's code with wine_* and WINE_TRACE,
and WINE_ERR, is not also very appealing either. Look, let's not try to
solve world's problems: this is not the debugging API to end all debugging
APIs. It's Wine's internal one. And it's present interface is _nice_, and
easy to use. And this is paramount for a good API. I think it would be a 
mistake to drop all that for a dubious generality. Any program using it is 
going to do something of the form:
#define DEBUG WINE_TRACE
Nobody is going to use the long symbols as they are anyway. In fact, I 
suggest that instead of the __WINE__ test for defining the short API we 
should test for WINE_DBG_SHORT_API so that others can use it as well. 
'Cause it's nice. And this way we can use the short API in all of our own
Winelib apps so there's no confusion anymore, _and_ we can stick to the
short API.

-- 
Dimi.