[Interprocess] Trying to include unistd.h on Windows?
We are using the Interprocess library to make use of shared memory within our code. We are experiencing the following problem when building on Windows. Some of our projects are trying to include unistd.h from workaround.hpp. It looks like this happens if BOOST_WINDOWS is not defined. Tracing back through the header files I pieced together that BOOST_WINDOWS is not defined if BOOST_DISABLE_WIN32 is defined (win32.hpp). And BOOST_DISABLE_WIN32 gets defined if _MSC_EXTENSIONS is not defined (visualc.hpp).
From the MSDN documentation, _MSC_EXTENSIONS is not defined if the Visual C++ Language Extensions are turned off, which in fact they are for these projects.
Has anyone else seen this and is there a workaround for getting Boost Interprocess to work on Windows in cases where the Visual C++ Language Extensions are turned off? Thanks, Derek -- Derek Kivi Senior Software Developer QuIC Financial Technologies Inc. Office: +1 403 210 8282 Mobile: +1 403 863 5204 derek.kivi@quic.com Risk. Managed. www.quic.com Confidentiality Notice: The information transmitted is intended only for the person(s) or entity(ies) to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination, 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 received this email in error, please contact the sender and delete the email and any related material from any computer. ver. QuIC 0707
Derek Kivi wrote:
Has anyone else seen this and is there a workaround for getting Boost Interprocess to work on Windows in cases where the Visual C++ Language Extensions are turned off?
Sorry, I haven't tried that, because Interprocess relies on boost config detection mechanisms to detect windows platforms. I think I'll need to change that detection mechanism with my own _WIN32 or similar detection. But that will be for 1.39 at least ;-) Can you fill a bug so that I don't forget this issue?
Thanks, Derek
Regards, Ion
Has anyone else seen this and is there a workaround for getting Boost Interprocess to work on Windows in cases where the Visual C++ Language Extensions are turned off?
Sorry, I haven't tried that, because Interprocess relies on boost config detection mechanisms to detect windows platforms. I think I'll need to
change that detection mechanism with my own _WIN32 or similar detection. But that will be for 1.39 at least ;-)
Can you fill a bug so that I don't forget this issue?
Done (It's bug #2722). I will try to figure out if we can re-enable the VC++ Language Extensions in the meantime :) Thanks Ion, Derek -- Derek Kivi Senior Software Developer QuIC Financial Technologies Inc. Office: +1 403 210 8282 Mobile: +1 403 863 5204 derek.kivi@quic.com Risk. Managed. www.quic.com Confidentiality Notice: The information transmitted is intended only for the person(s) or entity(ies) to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination, 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 received this email in error, please contact the sender and delete the email and any related material from any computer. ver. QuIC 0707
Derek Kivi wrote:
We are using the Interprocess library to make use of shared memory within our code. We are experiencing the following problem when building on Windows.
Some of our projects are trying to include unistd.h from workaround.hpp. It looks like this happens if BOOST_WINDOWS is not defined.
Tracing back through the header files I pieced together that BOOST_WINDOWS is not defined if BOOST_DISABLE_WIN32 is defined (win32.hpp). And BOOST_DISABLE_WIN32 gets defined if _MSC_EXTENSIONS is not defined (visualc.hpp).
From the MSDN documentation, _MSC_EXTENSIONS is not defined if the Visual C++ Language Extensions are turned off, which in fact they are for these projects.
Has anyone else seen this and is there a workaround for getting Boost Interprocess to work on Windows in cases where the Visual C++ Language Extensions are turned off?
sorry, for the really long delay. I've done some experiments and Interprocess can't be compiled without extensions because depends on Boost.DateTime which also needs them and because accesses to the windows API (and __cdecl and similar extensions are used in winapi declarations) require them. I haven't dedicated much time to this issue, but I have the impression that is not trivial to solve. Any help is appreciated.
Thanks, Derek
Regards, Ion
Derek Kivi wrote:
We are using the Interprocess library to make use of shared memory within our code. We are experiencing the following problem when building on Windows.
Some of our projects are trying to include unistd.h from workaround.hpp. It looks like this happens if BOOST_WINDOWS is not defined.
Tracing back through the header files I pieced together that BOOST_WINDOWS is not defined if BOOST_DISABLE_WIN32 is defined (win32.hpp). And BOOST_DISABLE_WIN32 gets defined if _MSC_EXTENSIONS is not defined (visualc.hpp).
From the MSDN documentation, _MSC_EXTENSIONS is not defined if the Visual C++ Language Extensions are turned off, which in fact they are for these projects.
Has anyone else seen this and is there a workaround for getting Boost Interprocess to work on Windows in cases where the Visual C++ Language Extensions are turned off?
sorry, for the really long delay. I've done some experiments and Interprocess can't be compiled without extensions because depends on Boost.DateTime which also needs them and because accesses to the windows API (and __cdecl and similar extensions are used in winapi declarations) require them. I haven't dedicated much time to this issue, but I have the impression that is not trivial to solve. Any help is appreciated.
Thanks Ion for looking into this. We have found a workaround for our particular case. In the past we have avoided this problem by having our class point to another implementation class that then included the Boost headers. The reason we weren't able to do that in this situation was that we were trying to create a class that we wanted to put into shared memory, so the use of pointers wouldn't work. Our workaround was to create a char array member in our class, and then in the cpp file for that class we used placement new to put a Boost shared memory string "into" the char array space. Maybe not the nicest code but it seems to work. Thanks again, Derek -- Derek Kivi Senior Software Developer QuIC Financial Technologies Inc. Office: +1 403 210 8282 Mobile: +1 403 863 5204 derek.kivi@quic.com Risk. Managed. www.quic.com Confidentiality Notice: The information transmitted is intended only for the person(s) or entity(ies) to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination, 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 received this email in error, please contact the sender and delete the email and any related material from any computer. ver. QuIC 0707
participants (2)
-
Derek Kivi -
Ion Gaztañaga