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