[system][chrono] header-only libs
Hi, after discussion with Ion about whether Boost.Interprocess could use Boost.Chrono and Boost.System he has found as major drawback that both are not header-only libs. I have implemented Boost.Chrono as a header only lib. If the user wants Boost.Chrono be a header-only lib s/he needs to define the BOOST_CHRONO_INLINED macro. While this could be useful, there is a problem as Boost.Chrono depends on Boost.System that is not a header-only lib. * I have added this on the configuration file #ifdef BOOST_CHRONO_INLINED #define BOOST_CHRONO_INLINE inline #define BOOST_CHRONO_DECL #else #define BOOST_CHRONO_INLINE // as before #endif * Copied all the .cpp files to the detail/inlined directory. * Renamed the .cpp file by .hpp files * Included in the old .cpp files the corresponding .hpp file in the detail/inlined directory * I've replaced the prefix suffix as follows: #ifndef BOOST_CHRONO_INLINED #include <boost/config/abi_prefix.hpp> // must be the last #include #endif #ifndef BOOST_CHRONO_INLINED #include <boost/config/abi_suffix.hpp> // pops abi_prefix.hpp pragmas #else #include <boost/chrono/detail/inlined/file_name.hpp> #endif * prefixed the definitions of the function in the .cpp files by BOOST_CHRONO_INLINE While doing this I have found a minor issue on Windows platform. I hve nedeed to sorrounded by () all the use of min and max functions on the test files to avoid the macros defined on the windows.h file. That means that a header-only lib could break user sources as it will include implicitly some platform files. Another drawback that I have no inspected yet could be the increase in size and compilation time of the user code. Beman do you mind if I try to make your library configurable as header-only, so Ion could use Boost.System and Boost.Chrono and preserve Boost.Interprocess as a header-only lib? Best, Vicente P.S. You can see the sandbox for the last modifications _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/
On 10/12/2010 06:37 PM, vicente.botet wrote:
While doing this I have found a minor issue on Windows platform. I hve nedeed to sorrounded by () all the use of min and max functions on the test files to avoid the macros defined on the windows.h file. That means that a header-only lib could break user sources as it will include implicitly some platform files.
Normally, header files should include the headers which provide definitions that they need. Unfortunately, windows.h does not follow the conventions and coding standards needed for that to be a safe thing to do. 1. It requires nonstandard language extensions 2. It defines common macro names like MIN, MAX, and TOKEN_TYPE 3. It requires configuration via preprocessor definitions before its inclusion, and yet it has a top-level #ifndef header guard which prevents multiple inclusion. 4. Last I checked (some time time ago), it had order-of-inclusion problems with other common MS library headers (like MFC and ATL). The majority of Windows code seems to include windows.h from a precompiled header at the top of most every translation unit. Suggestion: #ifndef _WINDOWS_ // or _INC_WINDOWS or whatever works empirically # error "Please include windows.h before this header (without defining NOGDI or NOUSER)" // or whatever parts are needed #endif As a long time Windows programmer, it seems entirely reasonable and unsurprising to me that a library header which depended on Windows OS features to expect that windows.h had been included ahead of time. I would prefer this over having mysterious order-of-inclusion issues with Boost headers. There will always be potential o-o-i issues with windows.h, but they can at least be made to result in a good explanation in the compiler output. - Marsh
Hi, ----- Original Message ----- From: "Marsh Ray" <marsh@extendedsubset.com> To: <boost@lists.boost.org> Cc: "vicente.botet" <vicente.botet@wanadoo.fr>; "Ion Gaztañaga" <igaztanaga@gmail.com> Sent: Wednesday, October 13, 2010 10:27 PM Subject: Re: [system][chrono] header-only libs
On 10/12/2010 06:37 PM, vicente.botet wrote:
While doing this I have found a minor issue on Windows platform. I hve nedeed to sorrounded by () all the use of min and max functions on the test files to avoid the macros defined on the windows.h file. That means that a header-only lib could break user sources as it will include implicitly some platform files.
Normally, header files should include the headers which provide definitions that they need. Unfortunately, windows.h does not follow the conventions and coding standards needed for that to be a safe thing to do.
1. It requires nonstandard language extensions 2. It defines common macro names like MIN, MAX, and TOKEN_TYPE 3. It requires configuration via preprocessor definitions before its inclusion, and yet it has a top-level #ifndef header guard which prevents multiple inclusion. 4. Last I checked (some time time ago), it had order-of-inclusion problems with other common MS library headers (like MFC and ATL).
I'm not a Windows programmer, and I was unaware of this order-of-inclusion issue. Boost.Interprocess and other libraries inlcude already <windows.h>, isn't it? have some authors found some trouble of this kind?
The majority of Windows code seems to include windows.h from a precompiled header at the top of most every translation unit.
Suggestion:
#ifndef _WINDOWS_ // or _INC_WINDOWS or whatever works empirically
# error "Please include windows.h before this header (without defining NOGDI or NOUSER)" // or whatever parts are needed
#endif
As a long time Windows programmer, it seems entirely reasonable and unsurprising to me that a library header which depended on Windows OS features to expect that windows.h had been included ahead of time. I would prefer this over having mysterious order-of-inclusion issues with Boost headers. There will always be potential o-o-i issues with windows.h, but they can at least be made to result in a good explanation in the compiler output.
- Marsh
What do others think of the proposed approach? Best, Vicente
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
From: "Marsh Ray" <marsh@extendedsubset.com>
The majority of Windows code seems to include windows.h from a precompiled header at the top of most every translation unit.
Suggestion:
#ifndef _WINDOWS_ // or _INC_WINDOWS or whatever works empirically
# error "Please include windows.h before this header (without defining NOGDI or NOUSER)" // or whatever parts are needed
#endif
As a long time Windows programmer, it seems entirely reasonable and unsurprising to me that a library header which depended on Windows OS features to expect that windows.h had been included ahead of time. I would prefer this over having mysterious order-of-inclusion issues with Boost headers. There will always be potential o-o-i issues with windows.h, but they can at least be made to result in a good explanation in the compiler output.
What do others think of the proposed approach?
The approach taken in the boost.thread headers is to define the types and functions needed in a "detail" namespace rather than include <windows.h> directly, unless BOOST_USE_WINDOWS_H is defined. See for example <boost/thread/win32/thread_primitives.hpp> Since the Windows API is a C API, the extern "C" declarations in the internal namespace will link against the global names provided by the library without publishing those names in the global namespace in files that include the header, or clashing with declarations from <windows.h> in those files that also include it. This causes a bit of difficulty where the definitions vary between SDK versions, but this is generally OK. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
----- Original Message ----- From: "Anthony Williams" <anthony.ajw@gmail.com> To: <boost@lists.boost.org> Sent: Thursday, October 14, 2010 12:07 AM Subject: Re: [boost] [system][chrono] header-only libs
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
From: "Marsh Ray" <marsh@extendedsubset.com>
The majority of Windows code seems to include windows.h from a precompiled header at the top of most every translation unit.
Suggestion:
#ifndef _WINDOWS_ // or _INC_WINDOWS or whatever works empirically
# error "Please include windows.h before this header (without defining NOGDI or NOUSER)" // or whatever parts are needed
#endif
As a long time Windows programmer, it seems entirely reasonable and unsurprising to me that a library header which depended on Windows OS features to expect that windows.h had been included ahead of time. I would prefer this over having mysterious order-of-inclusion issues with Boost headers. There will always be potential o-o-i issues with windows.h, but they can at least be made to result in a good explanation in the compiler output.
What do others think of the proposed approach?
The approach taken in the boost.thread headers is to define the types and functions needed in a "detail" namespace rather than include <windows.h> directly, unless BOOST_USE_WINDOWS_H is defined. See for example <boost/thread/win32/thread_primitives.hpp>
Since the Windows API is a C API, the extern "C" declarations in the internal namespace will link against the global names provided by the library without publishing those names in the global namespace in files that include the header, or clashing with declarations from <windows.h> in those files that also include it.
This causes a bit of difficulty where the definitions vary between SDK versions, but this is generally OK.
Anthony
I understand that you should have found some issues including <windows.h> file. I see that other libraries as FileSystem, Flyweithts, Interprocess, interlocked ... include it as you said: #if defined(BOOST_USE_WINDOWS_H) # include <windows.h> #else // extern declaration #endif Unfortunately not all files including <windows.h> are protected in this way. Is BOOST_USE_WINDOWS_H the offical macro to use? is this described somewhere? As there are quite a lot of files that includes some parts of <windows.h> some of them include the same declarations. I was wondering if we can not add a boost/detail/windows.hpp> file that will declare whatever is needed in Boost. Is this a good or a bad idea? As other platforms include other macros, shouldn't I do the same for this files? Thanks to both for signaling the trap and how to manage with. Best, Vicente
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
I understand that you should have found some issues including <windows.h> file. I see that other libraries as FileSystem, Flyweithts, Interprocess, interlocked ... include it as you said:
#if defined(BOOST_USE_WINDOWS_H) # include <windows.h> #else // extern declaration #endif
Unfortunately not all files including <windows.h> are protected in this way. Is BOOST_USE_WINDOWS_H the offical macro to use? is this described somewhere?
It isn't documented anywhere that I can see, but it is used by lots of libraries.
As there are quite a lot of files that includes some parts of <windows.h> some of them include the same declarations. I was wondering if we can not add a boost/detail/windows.hpp> file that will declare whatever is needed in Boost. Is this a good or a bad idea?
I think that's a bad idea, as lots of libraries will need to touch it, and it will end up getting big and bloated like <windows.h>. A boost/details/windows directory with a lot of special-purpose files would be better.
As other platforms include other macros, shouldn't I do the same for this files?
You mean <pthread.h> defines macros, so should we protect against that in the same way (for example)? If the header is as all-encompassing and messy as <windows.h> then yes. However, there are not many platforms where just about everything is a macro (e.g. because there are xxxA and xxxW versions of each function that takes a string), and there are macros that actively trample on common identifiers such as min and max (this even makes using std::min and std::max from <algorithm> tricky --- I end up using std::min<> everywhere to avoid being bitten). Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
----- Original Message ----- From: "Anthony Williams" <anthony.ajw@gmail.com> To: <boost@lists.boost.org> Sent: Thursday, October 14, 2010 8:53 AM Subject: Re: [boost] [system][chrono] header-only libs
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
I understand that you should have found some issues including <windows.h> file. I see that other libraries as FileSystem, Flyweithts, Interprocess, interlocked ... include it as you said:
#if defined(BOOST_USE_WINDOWS_H) # include <windows.h> #else // extern declaration #endif
Unfortunately not all files including <windows.h> are protected in this way. Is BOOST_USE_WINDOWS_H the offical macro to use? is this described somewhere?
It isn't documented anywhere that I can see, but it is used by lots of libraries.
As there are quite a lot of files that includes some parts of <windows.h> some of them include the same declarations. I was wondering if we can not add a boost/detail/windows.hpp> file that will declare whatever is needed in Boost. Is this a good or a bad idea?
I think that's a bad idea, as lots of libraries will need to touch it, and it will end up getting big and bloated like <windows.h>. A boost/details/windows directory with a lot of special-purpose files would be better.
Yes. This will much less monolitic. I will give it a try.
As other platforms include other macros, shouldn't I do the same for this files?
You mean <pthread.h> defines macros, so should we protect against that in the same way (for example)?
I was thinking to some Mac files that include other macros that can colapse with Boost identifiers. If I remember the inspection program has added some of these macros in his inspection list.
If the header is as all-encompassing and messy as <windows.h> then yes. However, there are not many platforms where just about everything is a macro (e.g. because there are xxxA and xxxW versions of each function that takes a string), and there are macros that actively trample on common identifiers such as min and max (this even makes using std::min and std::max from <algorithm> tricky --- I end up using std::min<> everywhere to avoid being bitten).
Oh yes std::min<>(a,b) should be more readable that (std::min)(a,b). At least this ca be applied when the function is a template. Thanks, Vicente
On 10/14/2010 01:53 AM, Anthony Williams wrote:
"vicente.botet"<vicente.botet@wanadoo.fr> writes:
As there are quite a lot of files that includes some parts of <windows.h> some of them include the same declarations. I was wondering if we can not add a boost/detail/windows.hpp> file that will declare whatever is needed in Boost. Is this a good or a bad idea?
I think that's a bad idea, as lots of libraries will need to touch it, and it will end up getting big and bloated like<windows.h>. A boost/details/windows directory with a lot of special-purpose files would be better.
Keep in mind <windows.h> has been aggressively accumulating APIs for over twenty years now. Except things with the best potential for modular interface design were systematically selected out to be implemented as COM interfaces. It's not big and bloated because stuff is added as a general-purpose project like Boost actually needs it and uses it. It's that way because Windows projects got into the habit of dumping the entire universe into a single precompiled header. If it gets too big you can split it into separate files later. I wouldn't worry about it unless it starts to become a problem. - Marsh
----- Original Message ----- From: "Marsh Ray" <marsh@extendedsubset.com> To: <boost@lists.boost.org> Cc: "Anthony Williams" <anthony.ajw@gmail.com> Sent: Friday, October 15, 2010 12:07 AM Subject: Re: [boost] [system][chrono] header-only libs
On 10/14/2010 01:53 AM, Anthony Williams wrote:
"vicente.botet"<vicente.botet@wanadoo.fr> writes:
As there are quite a lot of files that includes some parts of <windows.h> some of them include the same declarations. I was wondering if we can not add a boost/detail/windows.hpp> file that will declare whatever is needed in Boost. Is this a good or a bad idea?
I think that's a bad idea, as lots of libraries will need to touch it, and it will end up getting big and bloated like<windows.h>. A boost/details/windows directory with a lot of special-purpose files would be better.
If it gets too big you can split it into separate files later. I wouldn't worry about it unless it starts to become a problem.
Hi, I have started to define some files that allows to build Boost.Chrono and Boost.System without including <windows.h> file. basic_types.hpp // contain the basic types error_handling.hpp // error handling related time.hpp // time related process.hpp // process related thread.hpp // thread related The file name follows the naming of the main sections in http://msdn.microsoft.com/en-us/library/ee663300%28v=VS.85%29.aspx The user need to define BOOST_USE_WINDOWS_H if s/he prefers to use the <windows.h> file. These files should be modified and surely add new ones in order to provide everything the Boost lib needs. You can see them in the sandbox http://svn.boost.org/svn/boost/sandbox/chrono/boost/detail/win/ I have started to write some test that checks if the layout is the same (see http://svn.boost.org/svn/boost/sandbox/chrono/libs/chrono/test/win32_test.cp...). Where these kind of test should be placed? Anthony please, could you help me to fix this // @FIXME Which condition must be tested // #if !defined(_M_IX86) typedef __int64 LONGLONG_; // #else // typedef double LONGLONG_; // #endif If I uncomment the commented lines, I get an run time error in my machine AMD Athlon 62x2 Dual. I have reached to make Boost.System and Boost.Chrono header_only libs. The user needs to define BOOST_SYSTEM_INLINED and BOOST_CHRONO_INLINED respectively, but maybe a better name could be BOOST_SYSTEM_HEADER_ONLY and BOOST_CHRONO_HEADER_ONLY. You can see them in the sandbox http://svn.boost.org/svn/boost/sandbox/chrono/boost/system/ and http://svn.boost.org/svn/boost/sandbox/chrono/libs/system/ Beman, I have changed a little bit the logic under cygwin as the current version didn't work. Instead of # if defined(_WIN32) || defined(__CYGWIN__) // Windows default, including MinGW and Cygwin # define BOOST_WINDOWS_API # else # define BOOST_POSIX_API # endif I have defined # if (defined(_WIN32) || defined(__WIN32__) || defined(WIN32)) # define BOOST_SYSTEM_WINDOWS_API # else # define BOOST_SYSTEM_POSIX_API # endif Note the change in the macro name, so conflicts with other libs is avoided. With this little change every thing works now. I guess it is too late to merge these changes on the release branch, but at least the chage in the cygwin condition should be worth. Anyway, please let me know if this is the correct way to go and if this windows files could be incorporated in Boost. Best, Vicente
On Mon, Oct 18, 2010 at 5:37 AM, vicente.botet <vicente.botet@wanadoo.fr> wrote:
I have reached to make Boost.System and Boost.Chrono header_only libs. The user needs to define BOOST_SYSTEM_INLINED and BOOST_CHRONO_INLINED respectively, but maybe a better name could be BOOST_SYSTEM_HEADER_ONLY and BOOST_CHRONO_HEADER_ONLY.
You can see them in the sandbox http://svn.boost.org/svn/boost/sandbox/chrono/boost/system/ and http://svn.boost.org/svn/boost/sandbox/chrono/libs/system/
Sweet! As you may or may not know, cpp-netlib is currently dependent on Boost.Asio and thus Boost.System -- and it's a pain that Boost.System is not header-only. With this I definitely think cpp-netlib can really be used as a header-only library even with the dependencies in place.
With this little change every thing works now. I guess it is too late to merge these changes on the release branch, but at least the chage in the cygwin condition should be worth.
Anyway, please let me know if this is the correct way to go and if this windows files could be incorporated in Boost.
I look forward to being able to test this on trunk and maybe have it in Boost 1.45 as well. Thanks for the effort Vicente! This is definitely appreciated by the likes of me who like header-only libraries. -- Dean Michael Berris deanberris.com
----- Original Message ----- From: "vicente.botet" <vicente.botet@wanadoo.fr> To: <boost@lists.boost.org> Sent: Sunday, October 17, 2010 10:37 PM Subject: Re: [boost] [system][chrono] header-only libs
----- Original Message ----- From: "Marsh Ray" <marsh@extendedsubset.com> To: <boost@lists.boost.org> Cc: "Anthony Williams" <anthony.ajw@gmail.com> Sent: Friday, October 15, 2010 12:07 AM Subject: Re: [boost] [system][chrono] header-only libs
On 10/14/2010 01:53 AM, Anthony Williams wrote:
"vicente.botet"<vicente.botet@wanadoo.fr> writes:
As there are quite a lot of files that includes some parts of <windows.h> some of them include the same declarations. I was wondering if we can not add a boost/detail/windows.hpp> file that will declare whatever is needed in Boost. Is this a good or a bad idea?
I think that's a bad idea, as lots of libraries will need to touch it, and it will end up getting big and bloated like<windows.h>. A boost/details/windows directory with a lot of special-purpose files would be better.
If it gets too big you can split it into separate files later. I wouldn't worry about it unless it starts to become a problem.
Hi,
I have started to define some files that allows to build Boost.Chrono and Boost.System without including <windows.h> file.
basic_types.hpp // contain the basic types error_handling.hpp // error handling related time.hpp // time related process.hpp // process related thread.hpp // thread related
The file name follows the naming of the main sections in http://msdn.microsoft.com/en-us/library/ee663300%28v=VS.85%29.aspx
The user need to define BOOST_USE_WINDOWS_H if s/he prefers to use the <windows.h> file.
These files should be modified and surely add new ones in order to provide everything the Boost lib needs.
You can see them in the sandbox http://svn.boost.org/svn/boost/sandbox/chrono/boost/detail/win/
I have started to write some test that checks if the layout is the same (see http://svn.boost.org/svn/boost/sandbox/chrono/libs/chrono/test/win32_test.cp...). Where these kind of test should be placed?
Anthony please, could you help me to fix this
// @FIXME Which condition must be tested // #if !defined(_M_IX86) typedef __int64 LONGLONG_; // #else // typedef double LONGLONG_; // #endif
If I uncomment the commented lines, I get an run time error in my machine AMD Athlon 62x2 Dual.
I have reached to make Boost.System and Boost.Chrono header_only libs. The user needs to define BOOST_SYSTEM_INLINED and BOOST_CHRONO_INLINED respectively, but maybe a better name could be BOOST_SYSTEM_HEADER_ONLY and BOOST_CHRONO_HEADER_ONLY.
You can see them in the sandbox http://svn.boost.org/svn/boost/sandbox/chrono/boost/system/ and http://svn.boost.org/svn/boost/sandbox/chrono/libs/system/
<snip>
With this little change every thing works now. I guess it is too late to merge these changes on the release branch, but at least the chage in the cygwin condition should be worth.
Anyway, please let me know if this is the correct way to go and if this windows files could be incorporated in Boost.
Best, Vicente
Beman, I would like to know if you are yet interesteed on the header only version for Boost.System. Best, Vicente
On Sun, Jan 2, 2011 at 12:24 PM, vicente.botet <vicente.botet@wanadoo.fr> wrote:
Beman,
I would like to know if you are yet interesteed on the header only version for Boost.System.
Best, Vicente
I'm interested in the concept, but we would need to do a lot better that the code in the sandbox: Much of boost/system/detail/inlined/error_code.hpp code duplicates libs/system/src/error_code.cpp code. That isn't acceptable since it would create a maintenance nightmare. Code for each component needs to be defined in a single file, with macro magic to abstract away the difference between the library. Having to do every maintenance fix in two places isn't practical - the code will certainly diverge over time. The test framework also needs more work. Testing only the inlined version doesn't give enough confidence the library version works OK. --Beman
----- Original Message ----- From: "Beman Dawes" <bdawes@acm.org> To: "boost" <boost@lists.boost.org> Sent: Monday, January 03, 2011 2:56 AM Subject: Re: [boost] [system][chrono] header-only libs
On Sun, Jan 2, 2011 at 12:24 PM, vicente.botet <vicente.botet@wanadoo.fr> wrote:
Beman,
I would like to know if you are yet interesteed on the header only version for Boost.System.
Best, Vicente
I'm interested in the concept, but we would need to do a lot better that the code in the sandbox:
Much of boost/system/detail/inlined/error_code.hpp code duplicates libs/system/src/error_code.cpp code. That isn't acceptable since it would create a maintenance nightmare. Code for each component needs to be defined in a single file, with macro magic to abstract away the difference between the library. Having to do every maintenance fix in two places isn't practical - the code will certainly diverge over time.
Hi, Beman you have maybe missed the conditional compilation #if 1 #define BOOST_SYSTEM_SOURCE #include <boost/system/detail/inlined/error_code.hpp> #else // old code #endif I used this artifice to make easier possible evolutions of these file on trunk. So at the end the else part will be removed and there will be no duplicated code.
The test framework also needs more work. Testing only the inlined version doesn't give enough confidence the library version works OK.
I've adapted the Boost.Chrono Jamfile to tests all the configurations * shared link * static link * header only with BOOST_CHRONO_INLINED and BOOST_SYSTEM_INLINED * header only with BOOST_USE_WINDOWS_H as follows: rule chrono-run ( sources ) { return [ run $(sources) ../build//boost_chrono : : : <define>BOOST_USE_WINDOWS_H <library>/boost/system//boost_system : $(sources[1]:B)_shared ] [ run $(sources) ../build//boost_chrono/<link>static : : : <library>/boost/system//boost_system : $(sources[1]:B)_static ] [ run $(sources) : : : <define>BOOST_CHRONO_INLINED <define>BOOST_SYSTEM_INLINED : $(sources[1]:B)_header ] [ run $(sources) : : : <define>BOOST_CHRONO_INLINED <define>BOOST_USE_WINDOWS_H <define>BOOST_SYSTEM_INLINED : $(sources[1]:B)_header_win ] ; } Then we use it like [ chrono-run duration/arithmetic_pass.cpp ] I can add a similar kind of rule on Boost.System test so all the configurations are tested. Best, Vicente
On Mon, Jan 3, 2011 at 2:05 AM, vicente.botet <vicente.botet@wanadoo.fr> wrote:
Hi,
Beman you have maybe missed the conditional compilation
#if 1 #define BOOST_SYSTEM_SOURCE #include <boost/system/detail/inlined/error_code.hpp> #else // old code #endif
I used this artifice to make easier possible evolutions of these file on trunk. So at the end the else part will be removed and there will be no duplicated code.
Ah! Sorry, I missed that. Is there a reason for having the "inlined" subdirectory within boost/system/detail? Couldn't the two files just live in boost/system/detail? Could namespace boost::system::system_detail be renamed boost::system::detail? Just to keep the names a bit shorter. If you would prepare a patch against the current trunk, and send it to me, I'll apply it locally, and do some testing. Also, we need to document BOOST_USE_WINDOWS_H, if I understand Anthony correctly. Let's not forget that.
The test framework also needs more work. Testing only the inlined version doesn't give enough confidence the library version works OK.
I've adapted the Boost.Chrono Jamfile to tests all the configurations
...
I can add a similar kind of rule on Boost.System test so all the configurations are tested.
Yes, that's a necessity. We have enough time to get Boost.System inlining done for 1.46 if we get going on it right away. Thanks, --Beman
Beman Dawes wrote:
On Mon, Jan 3, 2011 at 2:05 AM, vicente.botet <vicente.botet@wanadoo.fr> wrote:
Hi,
Beman you have maybe missed the conditional compilation
#if 1 #define BOOST_SYSTEM_SOURCE #include <boost/system/detail/inlined/error_code.hpp> #else // old code #endif
I used this artifice to make easier possible evolutions of these file on trunk. So at the end the else part will be removed and there will be no duplicated code.
Ah! Sorry, I missed that.
Is there a reason for having the "inlined" subdirectory within boost/system/detail? Couldn't the two files just live in boost/system/detail?
No problem. I will change it.
Could namespace boost::system::system_detail be renamed boost::system::detail? Just to keep the names a bit shorter.
I will move it to boost::system::detail, but in some cases the use of system::detail:: will be needed to avoid ambiguity.
If you would prepare a patch against the current trunk, and send it to me, I'll apply it locally, and do some testing.
Also, we need to document BOOST_USE_WINDOWS_H, if I understand Anthony correctly. Let's not forget that.
I will try to write something and sent it to you.
The test framework also needs more work. Testing only the inlined version doesn't give enough confidence the library version works OK.
I've adapted the Boost.Chrono Jamfile to tests all the configurations
...
I can add a similar kind of rule on Boost.System test so all the configurations are tested.
Yes, that's a necessity.
We have enough time to get Boost.System inlining done for 1.46 if we get going on it right away.
I will try to send it to you soon with all the requested modifications. It would be really nice to be in time :) Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/system-chrono-header-only-libs-tp2992903p... Sent from the Boost - Dev mailing list archive at Nabble.com.
2010/10/12 vicente.botet <vicente.botet@wanadoo.fr>:
Hi,
after discussion with Ion about whether Boost.Interprocess could use Boost.Chrono and Boost.System he has found as major drawback that both are not header-only libs. I have implemented Boost.Chrono as a header only lib.
If the user wants Boost.Chrono be a header-only lib s/he needs to define the BOOST_CHRONO_INLINED macro. While this could be useful, there is a problem as Boost.Chrono depends on Boost.System that is not a header-only lib.
...
Beman do you mind if I try to make your library configurable as header-only, so Ion could use Boost.System and Boost.Chrono and preserve Boost.Interprocess as a header-only lib?
Having a header only option for Boost.System would be a nice addition, so it would be great if you could give it a try in the sandbox. My main concern is the inclusion of <windows.h>. While I see less harm in including <WinError.h>, I don't want to include any of the more problematic Windows headers, let alone <windows.h>. My initial reaction to Anthony's <boost/thread/win32/thread_primitives.hpp> is quite positive. I've also just provided the declarations for Win32 functions in some of my code, but thread_primitives.hpp does it in a more elegant way. --Beman --Beman
----- Original Message ----- From: "Beman Dawes" <bdawes@acm.org> To: "boost" <boost@lists.boost.org> Cc: "Ion Gaztañaga" <igaztanaga@gmail.com> Sent: Thursday, October 14, 2010 5:14 PM Subject: Re: [boost] [system][chrono] header-only libs 2010/10/12 vicente.botet <vicente.botet@wanadoo.fr>:
Hi,
after discussion with Ion about whether Boost.Interprocess could use Boost.Chrono and Boost.System he has found as major drawback that both are not header-only libs. I have implemented Boost.Chrono as a header only lib.
If the user wants Boost.Chrono be a header-only lib s/he needs to define the BOOST_CHRONO_INLINED macro. While this could be useful, there is a problem as Boost.Chrono depends on Boost.System that is not a header-only lib.
...
Beman do you mind if I try to make your library configurable as header-only, so Ion could use Boost.System and Boost.Chrono and preserve Boost.Interprocess as a header-only lib?
Having a header only option for Boost.System would be a nice addition, so it would be great if you could give it a try in the sandbox. My main concern is the inclusion of <windows.h>. While I see less harm in including <WinError.h>, I don't want to include any of the more problematic Windows headers, let alone <windows.h>. My initial reaction to Anthony's <boost/thread/win32/thread_primitives.hpp> is quite positive. I've also just provided the declarations for Win32 functions in some of my code, but thread_primitives.hpp does it in a more elegant way. --Beman _______________________________________________ I will try to manage with the inclusion of <windows.h> as proposed by Anthony, following the way is done in <boost/thread/win32/thread_primitives.hpp>. Ion, it seems that we could have Boost.System and Boost.Chrono (if accepted) as header-only libs in a near future :) Best, Vicente
Vicente Botet's header-only option for Boost.System is mostly working, and will be ready to commit to trunk soon. One question I'd like feedback on. The proposed macro that enables header-only configuration is BOOST_SYSTEM_INLINED, but BOOST_SYSTEM_HEADER_ONLY seems clearer to me. Do any other Boost libraries have header-only configurations? What macro do they use? Opinions welcome, --Beman
----- Original Message ----- From: "Beman Dawes" <bdawes@acm.org> To: "boost" <boost@lists.boost.org> Cc: "Ion Gaztañaga" <igaztanaga@gmail.com> Sent: Thursday, January 06, 2011 9:12 PM Subject: Re: [boost] [system][chrono] header-only libs
Vicente Botet's header-only option for Boost.System is mostly working, and will be ready to commit to trunk soon.
One question I'd like feedback on. The proposed macro that enables header-only configuration is BOOST_SYSTEM_INLINED, but BOOST_SYSTEM_HEADER_ONLY seems clearer to me.
Do any other Boost libraries have header-only configurations? What macro do they use?
Opinions welcome,
--Beman
I agree with you BOOST_SYSTEM_HEADER_ONLY is clearer. I don't think that there are other header-only configurable libraries in Boost, so it is up to you to select the appropiated name. I will adapt Boost.Chrono to the name you select. BTW, Happy new year to both, Vicente
Beman Dawes wrote:
Vicente Botet's header-only option for Boost.System is mostly working, and will be ready to commit to trunk soon.
Cool
One question I'd like feedback on. The proposed macro that enables header-only configuration is BOOST_SYSTEM_INLINED, but BOOST_SYSTEM_HEADER_ONLY seems clearer to me.
"HEADER_ONLY" is clearer. Given that most Boost libraries are header only, it seems as if those that provide an option to deviate from that norm, should do so explicitly. Thus, the name and behavior should be reversed: BOOST_XXXXX_AS_LIBRARY. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On Fri, Jan 7, 2011 at 4:37 AM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Beman Dawes wrote:
Vicente Botet's header-only option for Boost.System is mostly working, and will be ready to commit to trunk soon.
Cool
+1
One question I'd like feedback on. The proposed macro that enables header-only configuration is BOOST_SYSTEM_INLINED, but BOOST_SYSTEM_HEADER_ONLY seems clearer to me.
"HEADER_ONLY" is clearer.
+1
Given that most Boost libraries are header only, it seems as if those that provide an option to deviate from that norm, should do so explicitly. Thus, the name and behavior should be reversed: BOOST_XXXXX_AS_LIBRARY.
Right, but unfortunately for Boost.System's case, the default usage has been as a library, therefore an option should be explicitly turned on to deviate from its default distribution/usage scenario. Although it is possible to turn on BOOST_XXX_AS_LIBRARY by default in libraries that do distribute themselves as linked-in libraries and just have an option to turn it off at compile-time (which is actually tricky to do at best), maybe providing the BOOST_XXX_AS_LIBRARY for libraries that were once header-only to become externally-built-and-linked-in would make a better choice. HTH -- Dean Michael Berris about.me/deanberris
Dean Michael Berris wrote:
On Fri, Jan 7, 2011 at 4:37 AM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Given that most Boost libraries are header only, it seems as if those that provide an option to deviate from that norm, should do so explicitly. Thus, the name and behavior should be reversed: BOOST_XXXXX_AS_LIBRARY.
Right, but unfortunately for Boost.System's case, the default usage has been as a library, therefore an option should be explicitly turned on to deviate from its default distribution/usage scenario.
I did consider that, and my suggestion would be an implicit change for Boost.System users, but the question is whether there's any real problem that would make the shift troublesome for most users. Regardless of the Boost.System decision, all Boost libraries with such a build option should use the same approach. It should not be the case that some libraries require active changes to build as a library while others require active steps to build header-only. Since Boost.System is the only library in that situation -- at the moment, anyway -- Beman can choose as he sees fit, but defaulting to the expected norm for Boost libraries is ideal. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On Fri, Jan 7, 2011 at 5:32 AM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Dean Michael Berris wrote:
On Fri, Jan 7, 2011 at 4:37 AM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Given that most Boost libraries are header only, it seems as if those that provide an option to deviate from that norm, should do so explicitly. Thus, the name and behavior should be reversed: BOOST_XXXXX_AS_LIBRARY.
Right, but unfortunately for Boost.System's case, the default usage has been as a library, therefore an option should be explicitly turned on to deviate from its default distribution/usage scenario.
I did consider that, and my suggestion would be an implicit change for Boost.System users, but the question is whether there's any real problem that would make the shift troublesome for most users.
At least in my case, having a library that depends on Boost.System, it does break things. Consider the case when the user blindly just updates Boost, rebuilds the binaries, and starts seeing linker errors when suddenly Boost.System has just become header-only by default. This also messes up the packaging for Boost on Linux distributions too.
Regardless of the Boost.System decision, all Boost libraries with such a build option should use the same approach. It should not be the case that some libraries require active changes to build as a library while others require active steps to build header-only.
Since Boost.System is the only library in that situation -- at the moment, anyway -- Beman can choose as he sees fit, but defaulting to the expected norm for Boost libraries is ideal.
I don't know about "should all use the same approach". I don't see why complimentary options would be a problem. More specifically, those that have been by default header-only to suddenly have a non-header-only option should make that an option because it is the deviation from the status quo; and those that are not header-only to have that non-header-only option available. I don't see why offering BOOST_XXX_HEADER_ONLY for non-header-only libs and BOOST_XXX_AS_LIBRARY for header-only libs would be a problem. Am I missing something? -- Dean Michael Berris about.me/deanberris
El 06/01/2011 21:12, Beman Dawes escribió:
Do any other Boost libraries have header-only configurations? What macro do they use?
Although Boost.DateTime is not a header-only library, if you just need an small subset (e.g. the one used by Interprocess) you need to use BOOST_DATE_TIME_NO_LIB. But that's a different meaning, of course. BOOST_SYSTEM_HEADER_ONLY sounds fine. Best, Ion
participants (8)
-
Anthony Williams -
Beman Dawes -
Dean Michael Berris -
Ion Gaztañaga -
Marsh Ray -
Stewart, Robert -
Vicente Botet -
vicente.botet