[date_time] Patch for ticket #1740: date_time includes <windows.h>
Hello, date_time on Windows needs windows.h in order to have the definitions for FILETIME and GetSystemTimeAsFileTime and friends and does not use the same technique as other boost headers : if BOOST_USE_WINDOWS_H is defined include <windows.h> otherwise forward define functions as needed. In date_time is more difficult because it is a header_only library. Please find attached a patch to solve this issue and the test report of the library on the compiler I have at my disposal. I have taken precautions in order to ensure it will work on x64 Windows (please see comments related to the conversion between FILETIME and __int64) and I see no reason it should have changed for other platforms, but only testing will tell. Thank you, -- Emil Mieilica __________ Information from ESET NOD32 Antivirus, version of virus signature database 3506 (20081009) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
AMDG Emil Mieilica wrote:
date_time on Windows needs windows.h in order to have the definitions for FILETIME and GetSystemTimeAsFileTime and friends and does not use the same technique as other boost headers : if BOOST_USE_WINDOWS_H is defined include <windows.h> otherwise forward define functions as needed. In date_time is more difficult because it is a header_only library.
Please find attached a patch to solve this issue and the test report of the library on the compiler I have at my disposal.
I have taken precautions in order to ensure it will work on x64 Windows (please see comments related to the conversion between FILETIME and __int64) and I see no reason it should have changed for other platforms, but only testing will tell.
Can you attach this patch to the ticket so it doesn't get lost? In Christ, Steven Watanabe
Hello, Done. Hope it will be useful to everybody who uses this great library.
Can you attach this patch to the ticket so it doesn't get lost?
In Christ, Steven Watanabe
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
__________ Information from ESET NOD32 Antivirus, version of virus signature database 3514 (20081011) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
Emil Mieilica wrote:
Hello, Done. Hope it will be useful to everybody who uses this great library.
Can you attach this patch to the ticket so it doesn't get lost?
Just a technical comment on the suggested patch. Is it really wise / legal to replicate the Windows API declarations in Boost. While it has the nice property of removing the windows.h dependency it seems to me that we might be on thin legal ice there. Jeff
Jeff Garland escribió:
Emil Mieilica wrote:
Hello, Done. Hope it will be useful to everybody who uses this great library.
Can you attach this patch to the ticket so it doesn't get lost?
Just a technical comment on the suggested patch. Is it really wise / legal to replicate the Windows API declarations in Boost.
Isn't that exactly what other libs such as WINE do? See http://source.winehq.org/source/include/ Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
joaquin@tid.es wrote:
Jeff Garland escribió:
Emil Mieilica wrote:
Hello, Done. Hope it will be useful to everybody who uses this great library.
Can you attach this patch to the ticket so it doesn't get lost?
Just a technical comment on the suggested patch. Is it really wise / legal to replicate the Windows API declarations in Boost.
Isn't that exactly what other libs such as WINE do? See
Yeah, I guess they would have to since they are an emulation of the Win32 api. AFAIK we've never taken this approach in Boost so I think we should talk thru if it's acceptable before putting it in. If it is acceptable, I guess the other question might be if it belongs in config instead of an individual library. Jeff
Jeff Garland <jeff@crystalclearsoftware.com> writes:
joaquin@tid.es wrote:
Jeff Garland escribió:
Emil Mieilica wrote:
Hello, Done. Hope it will be useful to everybody who uses this great library.
Can you attach this patch to the ticket so it doesn't get lost?
Just a technical comment on the suggested patch. Is it really wise / legal to replicate the Windows API declarations in Boost.
Isn't that exactly what other libs such as WINE do? See
Yeah, I guess they would have to since they are an emulation of the Win32 api. AFAIK we've never taken this approach in Boost so I think we should talk thru if it's acceptable before putting it in. If it is acceptable, I guess the other question might be if it belongs in config instead of an individual library.
boost/detail/lwm_win32_cs.hpp does this for CRITICAL_SECTION, and boost/thread/win32/thread_primitives.hpp does this for some APIs. In both cases the structures and APIs are redeclared in a nested namespace in boost, so as not to clash with the declarations in the global namespace should someone include <windows.h> outside the boost headers. I've attached the patch I've been using locally. The "filetime.hpp" goes in boost/date_time. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL #ifndef BOOST_DATE_TIME_FILETIME_HPP #define BOOST_DATE_TIME_FILETIME_HPP // (C) Copyright 2008 Anthony Williams // // Distributed under the Boost Software License, Version 1.0. (See // accompanying file LICENSE_1_0.txt or copy at // http://www.boost.org/LICENSE_1_0.txt) #ifdef BOOST_HAS_FTIME #ifdef BOOST_USE_WINDOWS_H #include <windows.h> namespace boost { namespace detail { namespace win32 { typedef FILETIME file_time; typedef SYSTEMTIME system_time; using ::GetSystemTime; using ::GetSystemTimeAsFileTime; using ::FileTimeToLocalFileTime; using ::SystemTimeToFileTime; } } } #else namespace boost { namespace detail { namespace win32 { extern "C" { struct file_time { unsigned long dwLowDateTime; unsigned long dwHighDateTime; }; struct system_time { unsigned short wYear; unsigned short wMonth; unsigned short wDayOfWeek; unsigned short wDay; unsigned short wHour; unsigned short wMinute; unsigned short wSecond; unsigned short wMilliseconds; }; __declspec(dllimport) void __stdcall GetSystemTimeAsFileTime(file_time*); __declspec(dllimport) int __stdcall FileTimeToLocalFileTime(const file_time*,file_time*); __declspec(dllimport) void __stdcall GetSystemTime(system_time*); __declspec(dllimport) int __stdcall SystemTimeToFileTime(const system_time*,file_time*); } } } } #endif #endif #endif
At 8:42 AM -0700 10/14/08, Jeff Garland wrote:
Just a technical comment on the suggested patch. Is it really wise / legal to replicate the Windows API declarations in Boost.
Isn't that exactly what other libs such as WINE do? See
Yeah, I guess they would have to since they are an emulation of the Win32 api. AFAIK we've never taken this approach in Boost so I think we should talk thru if it's acceptable before putting it in. If it is acceptable, I guess the other question might be if it belongs in config instead of an individual library.
boost.thread already does this: see, for example, the #else clause of the #if defined( BOOST_USE_WINDOWS_H ) block in trunk version of boost/thread/win32/thread_primitives.hpp. This approach has also been at least discussed for and possibly adopted by asio, interprocess, and filesystem, all for the same reason that including windows.h is considered pretty intrusive by some people.
participants (6)
-
Anthony Williams -
Emil Mieilica -
Jeff Garland -
joaquin＠tid.es -
Kim Barrett -
Steven Watanabe