Re: [Stlport-devel] _windows.h for VC8/CE

[<fra...@fr...>]

Hi Uli

    As you said _windows.h is here to avoid to include all the world 
with native windows.h. Reason of that can be both improve compilation 
time and avoid conflict.

     Your fix work for EVC because in _evc.h you will find a 
_native_headers.h include that define everything that you need to access 
native headers. For other compilers it is done later in config/feature.h 
to give STLport user an opportunity to customize the native include 
path. I guess your desktop build was not done with EVC, was it ?

    The only fix I can think about is to avoid include of any platform 
header in _windows.h duplicating all the necessary typedef, is that 
possible ?

Just a comment about your post, you are giving the following includes:

...
stl/config/_system.h
stl/config/_windows.h
windows.h
...

Haven't you miss something between _system.h and _windows.h. I am doing some modifications in _system.h to report failure of platform or compiler detection so if there is really nothing between those 2 includes it will result in a #error.

Bests

Ulrich Eckhardt wrote:
> Hello!
>
> I still have one more little bug in the VC8/CE port. The problem arises when 
> you try to include any Windows header before including an STLport header. The 
> include-chain then roughly goes windows.h, windef.h, winnt.h, ctype.h (this 
> one being an STLport header) and finally stl/config/_windows.h. It fails 
> there because some things haven't been defined yet (e.g. HWND).
>
> What I was doing up to now was to simply #include <iostream> before anything 
> else, but that is a bad workaround. Now, after some trying to understand 
> what's going on I just replaced the whole of STLport's _windows.h with the 
> following two lines:
>
> #include <windows.h>
> #define _STLPInterlockedExchangePointer(x,y) \
>   (PVOID)InterlockedExchange( (PLONG)(x), (LONG)(y));
>
> Actually that plus include guards and the code at the beginning to set 
> endianess. What is unfortunate is that InterlockedExchangePointer is 
> available but it requires a void** and not a void*volatile* as first 
> argument, hence the ugly macro.
>
> Anyhow, using those two lines, I can compile both unittests and my CE code. 
> However, the same code compiled for desktop win32 fails because it uses 
> _STLP_NATIVE_C_HEADER before it is defined. This comes from this chain of 
> includes:
> stlport/stdlib.h
> stl/_prolog.h
> stl/config/features.h
> ...
> stl/config/_system.h
> stl/config/_windows.h
> windows.h
> ...
> vadefs.h
> stlport/stdarg.h
>
> I guess STLport's _windows.h is intended to work around all the many headers 
> and the ensuing circular dependency that the native windows.h includes. What 
> I don't understand is how to porperly extend/fix it though nor do I know what 
> exactly it has to provide.
>
>
> Another (possibly related) problem is that I currently get loads of errors 
> compiling the library and unittests (strangely enough not with my code...) 
> pointing to some system headers and saying "warning C4201: nonstandard 
> extension used: anonymous union/struct". Since those are just warnings, I'm 
> happy to ignore them but they are annoying. I remember seeing the same under 
> eVC4, but I don't remember how I got rid of it. I think there was also some 
> broken code in the SDK where warnings were disabled and afterwards reset to 
> the default instead of being pushed/popped.
>
> thankful for any idea
>
> Uli
>
>
> ****************************************************
> Visit our website at <http://www.domino-printing.com/>
> ****************************************************
> This Email and any files transmitted with it are intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any reading, redistribution, disclosure or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient please contact the sender immediately and delete the material from your computer.
>
> E-mail may be susceptible to data corruption, interception, viruses and unauthorised amendment and Domino UK Limited does not accept liability for any such corruption, interception, viruses or amendment or their consequences.
> ****************************************************
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Stlport-devel mailing list
> Stl...@li...
> https://lists.sourceforge.net/lists/listinfo/stlport-devel
>
>
>