[ros-bugs] [Bug 3332] About WINE debug code.

[ReactOS.Bugzilla at www.reactos.org]

http://www.reactos.org/bugzilla/show_bug.cgi?id=3332





--- Comment #6 from Carlo Bramix <carlo.bramix at libero.it>  2008-06-23 12:00:14 CET ---
We could discuss about the best choice, but I agree to follow the coding
standard, whatever it is.
For me it is important to remove that debug stuff in Release mode!

Anyways if I can give my weak opinion, I hope that you won't do your solution
(1).
As explained into the text that you highlighted to me, such opcodes can be
allowed if they are motivated and they are well constructed for portability
issues like:

#if defined i386
#include "i386.h"
#elif defined ARM
#include "arm.h"
#elif ...

or 

#if defined linux
#include "mylinux.h"
#elif defined windows
#include "mywindows.h"
#elif ...

Instead, I see that codes as "common" objects, it does not matter if, for
example, we are compiling for a different platform or a different architecture.
It just depends on itself (the debug stuff), so for me it has no much sense
moving those functions into a separete file (besides, of course, following the
existing coding pratice).

Personally I also hope that you won't apply the solution (2) which transforms
those static functions into global ones.

At last, I think the sentence "#ifdef and #if are last resorts" should be
interpreted a bit.
I agree that a source code can be less readable when those keywords are widely
used.
However, I don't think that a source can be defined "unreadable" if there is
just one "#ifdef" into it.
They could also be last resorts, but we should remember that the code can be
something lower than the application layer, or the "gratuitous optimization" is
what it makes the difference (I'm talking for experience).
They are instruments, and as all instruments they need to be used smartly.

But at the end, for this problem, the final result will be the same,
independently from the adopted solution, so I hope that a way or another could
be accepted for reaching the target (removing WINE's debug stuff when in
release mode).


-- 
Configure bugmail: http://www.reactos.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.