Re: commctrl.h: Add WC_STATIC

[Felix Nawothnig]

Frank Richter wrote:
> +#define WC_STATICA	"Static"
> +#if defined(__GNUC__)
> +# define WC_STATICW (const WCHAR []){ 'S','t','a', 't','i','c',0 }
> +#elif defined(_MSC_VER)
> +# define WC_STATICW L"Static"
> +#else
> +static const WCHAR WC_STATICW[] = { 'S','t','a','t','i','c',0 };
> +#endif
> +#define WC_STATIC		WINELIB_NAME_AW(WC_STATIC)
> +

I'm curious, what is the reason for the special case handling for MSVC 
and GCC when we have to do the portable way anyway?

Felix

commctrl.h: Add WC_STATIC

[Dmitry Timoshkov]

"Felix Nawothnig" <felix.nawothnig(a)t-online.de> wrote:
> Frank Richter wrote:
> > +#define WC_STATICA "Static"
> > +#if defined(__GNUC__)
> > +# define WC_STATICW (const WCHAR []){ 'S','t','a', 't','i','c',0 }
> > +#elif defined(_MSC_VER)
> > +# define WC_STATICW L"Static"
> > +#else
> > +static const WCHAR WC_STATICW[] = { 'S','t','a','t','i','c',0 };
> > +#endif
> > +#define WC_STATIC WINELIB_NAME_AW(WC_STATIC)
> > +
>
> I'm curious, what is the reason for the special case handling for MSVC 
> and GCC when we have to do the portable way anyway?

(const WCHAR []) cast is not portable (gcc only) and L"string" syntax produces
different results on different platforms depending on the compiler's builtin
wchar_t size.

-- 
Dmitry.

commctrl.h: Add WC_STATIC

[Felix Nawothnig]

Dmitry Timoshkov wrote:
> > > +#define WC_STATICA "Static"
> > > +#if defined(__GNUC__)
> > > +# define WC_STATICW (const WCHAR []){ 'S','t','a', 't','i','c',0 }
> > > +#elif defined(_MSC_VER)
> > > +# define WC_STATICW L"Static"
> > > +#else
> > > +static const WCHAR WC_STATICW[] = { 'S','t','a','t','i','c',0 };
> > > +#endif
> > > +#define WC_STATIC WINELIB_NAME_AW(WC_STATIC)
> > > +
> > > I'm curious, what is the reason for the special case handling for MSVC 
> > > and GCC when we have to do the portable way anyway?
> > > (const WCHAR []) cast is not portable (gcc only) and L"string" syntax 
> > > produces
> > > different results on different platforms depending on the compiler's 
> > > builtin
> > > wchar_t size.

I'm aware of that, my question remains: Why do we _additionally_ provide 
two unportable ways when there is a portable one?

Felix

commctrl.h: Add WC_STATIC

[Mike McCormack]

Felix Nawothnig wrote:
> > +#define WC_STATICA    "Static"
> > +#if defined(__GNUC__)
> > +# define WC_STATICW (const WCHAR []){ 'S','t','a', 't','i','c',0 }
> > +#elif defined(_MSC_VER)
> > +# define WC_STATICW L"Static"
> > +#else
> > +static const WCHAR WC_STATICW[] = { 'S','t','a','t','i','c',0 };
> > +#endif
> > +#define WC_STATIC        WINELIB_NAME_AW(WC_STATIC)
> I'm curious, what is the reason for the special case handling for MSVC 
> and GCC when we have to do the portable way anyway?

I can see two reasons:

* The portable way adds a (non-standard) symbol.
* The static string declaration may not be discarded by some compilers, 
so it may needlessly increase the size of our binaries.

Mike

commctrl.h: Add WC_STATIC

[Felix Nawothnig]

Mike McCormack wrote:
> > I'm curious, what is the reason for the special case handling for MSVC 
> > and GCC when we have to do the portable way anyway?
> > I can see two reasons:
>
> * The portable way adds a (non-standard) symbol.

This could be fixed by adding a _ prefix.
> * The static string declaration may not be discarded by some compilers, 
> so it may needlessly increase the size of our binaries.

Unless MSVC or GCC do not do this optimization (and I'm sure both do) 
this is no argument.

Actually those 2 non-standard ways put additional burden on the 
optimizer - if one of those wide string literals is used multiple times 
the optimizer has to make sure that the compiler doesn't generate a copy 
for each reference (and I'm not so sure if GCC / MSVC do this, 
especially since writeable strings (yea, it's const but still) were only 
recently forbidden by GCC and I guess they are allowed in MSVC).

Felix

commctrl.h: Add WC_STATIC

[Mike McCormack]

Felix Nawothnig wrote:
> This could be fixed by adding a _ prefix.

Adding another prefix fixes nothing.  The original Windows SDK headers 
don't export a symbol, and we do.  It's simply good practice to try and 
be as close as possible to the original SDK.

Mike