"Troy Rollo" wine@troy.rollo.name wrote:
#ifdef INITGUID +#ifdef __cplusplus #define DEFINE_GUID(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8) \
extern const GUID name = \- { l, w1, w2, { b1, b2, b3, b4, b5, b6, b7, b8 } }
+#else +#define DEFINE_GUID(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8) \ const GUID name = \ { l, w1, w2, { b1, b2, b3, b4, b5, b6, b7, b8 } } +#endif #else #define DEFINE_GUID(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8) \ extern const GUID name
PSDK has 'extern' for both C and CPP cases, just the CPP one has 'extern "C"'. We have to use the same approach.
On Wednesday 31 August 2005 19:10, Dmitry Timoshkov wrote: onst GUID name
PSDK has 'extern' for both C and CPP cases, just the CPP one has 'extern "C"'. We have to use the same approach.
Why? We have to get the same *result*, but that doesn't mean we have to have the same *code*.
'extern "C"' on a non-member non-function global is perfectly meaningless to most C++ compilers. As far as I am aware, only MSVC++ mangles global variables. The 'extern "C"' is thus there to deal with a broken feature of the MSVC++ compiler, and is not applicable here unless somebody wants to compile C++ for Winelib using MSVC++ without the PSDK - something which I suspect would have many more obstacles in its path than just this.
Unless there is a functional reason for doing exactly what is done in the PSDK we should actually avoid, as far as possible, doing so. We walk a fine line as it is on copyright law. Copying form that is not dictated by function takes us into more dangerous territory (see Feist Publications v Rural Telephone Service).
Hi,
On 8/31/05, Troy Rollo troy@rollo.com wrote:
'extern "C"' on a non-member non-function global is perfectly meaningless to most C++ compilers. As far as I am aware, only MSVC++ mangles global variables. The 'extern "C"' is thus there to deal with a broken feature of the MSVC++ compiler, and is not applicable here unless somebody wants to compile C++ for Winelib using MSVC++ without the PSDK - something which I suspect would have many more obstacles in its path than just this.
Well yes some of us do. I work to keep the Wine SDK compatible with the PSDK because we have developed a MSVC backend in the ReactOS build system and one day (God willing) I will get the ReactOS Project to use Wine headers rather than w32api headers. As such it needs to be able to compile applications on MSVC and gcc.
Thanks Steven
On Thu, 1 Sep 2005 14:30, Steven Edwards wrote:
Well yes some of us do. I work to keep the Wine SDK compatible with the PSDK because we have developed a MSVC backend in the ReactOS build system and one day (God willing) I will get the ReactOS Project to use Wine headers rather than w32api headers. As such it needs to be able to compile applications on MSVC and gcc.
OK. I'll submit a version that can deal with this as well after I've tested it (should be some time tomorrow).
takes us into more dangerous territory (see Feist Publications v Rural Telephone Service).
Correction... Computer Associates v Altai (lesson: don't sent email requiring some precision before being fully awake).
-- troy@rollo.com - Sydney, Australia
-
Dmitry Timoshkov -
Steven Edwards -
Troy Rollo -
Troy Rollo