Mike Hearn mike@navi.cx writes:
The lack of this confused me for a few minutes, might as well stick it in.
It's missing because it violates namespace rules. The other debugstr functions are here for historical reasons but we shouldn't add new ones.
On Sat, 2004-08-07 at 16:00 -0700, Alexandre Julliard wrote:
It's missing because it violates namespace rules. The other debugstr functions are here for historical reasons but we shouldn't add new ones.
OK, I suspected that might be the case but inside of Wines code why do we have to prefix things with wine? For Winelib (ie external) source I can understand that, but we already know there are no conflicts inside Wine.
On Sat, Aug 07, 2004 at 04:00:25PM -0700, Alexandre Julliard wrote:
Mike Hearn mike@navi.cx writes:
The lack of this confused me for a few minutes, might as well stick it in.
It's missing because it violates namespace rules. The other debugstr functions are here for historical reasons but we shouldn't add new ones.
Please let's not do this inside of Wine. Clearly, we want to export everthing with the WINE_/wine_ prefix, I'm not debating this. I can also see that we want to be consistent, and that's a good thing -- for all but the debugging API our symbol invokations are far and few in between, and it actually *helps* to see when we call a non-standard API.
However, the exact opposite holds for the debugging API: it is the most used API in the source, and it doesn't help to know that it's a Wine API. Having the prefix on every single symbol of this API would not only greatly clutter the code, but I'd also claim it's not the style we should promote. People should try to write portable Win32 code (and here portable is between MS Windows and Wine), and a wine_ prefix is a big bad warning sign. One should be able to grep the sources for wine_ to figure out such places. Hiding them inside mountains of debug calls will not help.
Usage of the debug API should not tie the code to Wine, and the source should make it clear. We should promote symbol renaming for Winelib apps (just like we do in Wine today): #define ERR WINE_ERR #define TRACE WINE_TRACE ...
Apart for much cleaner code, it's also useful, as I can see many people do: #ifdef WINE # define ERR WINE_ERR # define TRACE WINE_TRACE ... #else # define ERR printf # define TRACE printf ... #endif
I have a sentimental attachment to the Wine's debugging API, as it was the first project that I undertook in Wine. It was what "hooked" me in. This may be a small issue, and probably I shouldn't care, but I can't help it. I truely think requiring the WINE_/wine_ prefix inside of Wine for commonly used symbols in the debugging API is not a good direction, and I really hope we can revisit this decision.
"Dimitrie O. Paun" dpaun@rogers.com writes:
Apart for much cleaner code, it's also useful, as I can see many people do: #ifdef WINE # define ERR WINE_ERR # define TRACE WINE_TRACE ... #else # define ERR printf # define TRACE printf ... #endif
I have a sentimental attachment to the Wine's debugging API, as it was the first project that I undertook in Wine. It was what "hooked" me in. This may be a small issue, and probably I shouldn't care, but I can't help it. I truely think requiring the WINE_/wine_ prefix inside of Wine for commonly used symbols in the debugging API is not a good direction, and I really hope we can revisit this decision.
I agree for the ERR etc. macros, but I don't think the debugstr functions are the same issue at all. You can't really #define them to something else anyway, you need to link with libwine to make them available. So I think it makes much more sense to keep the wine_ prefix for them, so that usage is consistent between Wine and Winelib code.
-
Alexandre Julliard -
Dimitrie O. Paun -
Mike Hearn