[thread] Can't use boost/thread/mutex.hpp without boost_system
Hello, The Boost.Thread version in trunk does not allow to use simple mutex as it was possible before: #include <boost/thread/mutex.hpp> #include <iostream> int main() { boost::mutex l; { boost::unique_lock<boost::mutex> g(l); std::cout << "Test" << std::endl; } } Was working fine without linking with 1.48 and 1.46 but now it fails with current trunk version requiring dependency on Boost.System. It breaks some code and breaks at least Boost.Locale. Is this change intentional or a bug? If it is intentional I'd like to know to fix Boost.Locale if not then is it possible to fix it. Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/
Artyom Beilis wrote
Hello,
The Boost.Thread version in trunk does not allow to use simple mutex as it was possible before:
#include <boost/thread/mutex.hpp> #include <iostream>
int main() { boost::mutex l; { boost::unique_lock<boost::mutex> g(l); std::cout << "Test" << std::endl; } }
Was working fine without linking with 1.48 and 1.46 but now it fails with current trunk version requiring dependency on Boost.System.
Hi, I was not aware that Boost.Thread was working as a header only library. I have added some support to report errors following the C++11 standard, using Boost.System. You need to link with Boost.System library. Is this an issue?
It breaks some code and breaks at least Boost.Locale.
Is there some break other than the need to link with?
Is this change intentional or a bug? If it is intentional I'd like to know to fix Boost.Locale if not then is it possible to fix it.
It was intentional. I hope that you just need to link in addition with boost_system. Aside, I proposed Beman a patch to make Boost.System header-only when I tried to make Boost.Chrono header-only but he didn't accepted it :(. I'm trying to make some changes that are code compatible, but I was unable to avoid the link issue. Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/thread-Can-t-use-boost-thread-mutex-hpp-w... Sent from the Boost - Dev mailing list archive at Nabble.com.
The Boost.Thread version in trunk does not allow to use simple mutex as it was possible before:
#include <boost/thread/mutex.hpp> #include <iostream>
int main() { boost::mutex l; { boost::unique_lock<boost::mutex> g(l); std::cout << "Test" << std::endl; } }
Was working fine without linking with 1.48 and 1.46 but now it fails with current trunk version requiring dependency on Boost.System.
Hi,
I was not aware that Boost.Thread was working as a header only library. I have added some support to report errors following the C++11 standard, using Boost.System. You need to link with Boost.System library. Is this an issue?
Till now I could use Boost.Locale without dependencies on Thread when it was working without ICU. It is not a problem to add a dependency. I just thought if there is a some kind of lightweight mutex that can be used without boost.thread? I can bring something on my own (it is really 20 lines of code) just maybe there is something ready for roll... If not I'll add dependency on system.
It breaks some code and breaks at least Boost.Locale.
Is there some break other than the need to link with?
No, it there is not other problems. Artyom
Le 18/01/12 15:09, Artyom Beilis a écrit :
The Boost.Thread version in trunk does not allow to use simple mutex as it was possible before:
#include<boost/thread/mutex.hpp> #include<iostream>
int main() { boost::mutex l; { boost::unique_lock<boost::mutex> g(l); std::cout<< "Test"<< std::endl; } }
Was working fine without linking with 1.48 and 1.46 but now it fails with current trunk version requiring dependency on Boost.System.
Hi,
I was not aware that Boost.Thread was working as a header only library. I have added some support to report errors following the C++11 standard, using Boost.System. You need to link with Boost.System library. Is this an issue?
Till now I could use Boost.Locale without dependencies on Thread when it was working without ICU. It is not a problem to add a dependency.
I just thought if there is a some kind of lightweight mutex that can be used without boost.thread? I can bring something on my own (it is really 20 lines of code) just maybe there is something ready for roll...
If not I'll add dependency on system.
I really thought, that people was looking for a C++11 compliant implementation. I see now that I might be wrong. As for Boost.Chrono, I could add the dependency to Boost.System conditionally and come back to the preceding exceptions. Let me know if it is worth doing it. Best, Vicente
On Thu, Jan 19, 2012 at 8:22 AM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> wrote:
I really thought, that people was looking for a C++11 compliant implementation. I see now that I might be wrong.
As for Boost.Chrono, I could add the dependency to Boost.System conditionally and come back to the preceding exceptions. Let me know if it is worth doing it.
Best, Vicente
I can't speak for others, but I know that I personally am interested in improved C++11 compliance for Boost.Thread.
From: Vicente J. Botet Escriba <vicente.botet@wanadoo.fr>
I just thought if there is a some kind of lightweight mutex that can be used without boost.thread? I can bring something on my own (it is really 20 lines of code) just maybe there is something ready for roll...
If not I'll add dependency on system.
I really thought, that people was looking for a C++11 compliant implementation. I see now that I might be wrong.
As for Boost.Chrono, I could add the dependency to Boost.System conditionally and come back to the preceding exceptions. Let me know if it is worth doing it.
Best, Vicente
I think I'll just switch to boost::detail::lightweight_mutex in all places where I don't really need Boost.Thread Artyom
On 18/01/12 14:01, Vicente Botet wrote:
I was not aware that Boost.Thread was working as a header only library.
This was a much-requested feature, so I made sure that boost::mutex at least was usable header-only. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++11 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> On 18/01/12 14:01, Vicente Botet wrote:
I was not aware that Boost.Thread was working as a header only library.
This was a much-requested feature, so I made sure that boost::mutex at least was usable header-only.
Anthony
So would this be fixed or I should switch to lightweight mutex? Artyom
Le 19/01/12 13:12, Artyom Beilis a écrit :
----- Original Message -----
From: Anthony Williams<anthony.ajw@gmail.com> On 18/01/12 14:01, Vicente Botet wrote:
I was not aware that Boost.Thread was working as a header only library. This was a much-requested feature, so I made sure that boost::mutex at least was usable header-only.
Oh, I remember that now. So would this be fixed or I should switch to lightweight mutex?
As far as Boost.System is not-header-only we can not have both: boost::mutex header-only and compliant with c++11. As said before, I could let the user the possibility to set Boost.Thread to don't use Boost.System via BOOST_THREAD_DONT_USE_SYSTEM. Artyom, Anthony is this satisfactory for you? Best, Vicente
On 19/01/12 21:39, Vicente J. Botet Escriba wrote:
Le 19/01/12 13:12, Artyom Beilis a écrit :
----- Original Message -----
From: Anthony Williams<anthony.ajw@gmail.com> On 18/01/12 14:01, Vicente Botet wrote:
I was not aware that Boost.Thread was working as a header only library. This was a much-requested feature, so I made sure that boost::mutex at least was usable header-only.
Oh, I remember that now. So would this be fixed or I should switch to lightweight mutex?
As far as Boost.System is not-header-only we can not have both: boost::mutex header-only and compliant with c++11. As said before, I could let the user the possibility to set Boost.Thread to don't use Boost.System via BOOST_THREAD_DONT_USE_SYSTEM. Artyom, Anthony is this satisfactory for you?
That sounds reasonable to me: if people wish to use Boost.Thread header-only then they can define the macro, but anyone who needs to use the full features must link against the library, so can cope with the additional dependency on Boost.System. It would be great if we could ensure that code with incompatible settings wouldn't link. We could mask out the parts of Boost.Thread that do need the library with that macro, for starters, so we don't need separate builds of the library with and without that macro. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++11 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
Le 20/01/12 08:42, Anthony Williams a écrit :
On 19/01/12 21:39, Vicente J. Botet Escriba wrote:
Le 19/01/12 13:12, Artyom Beilis a écrit :
----- Original Message -----
From: Anthony Williams<anthony.ajw@gmail.com> On 18/01/12 14:01, Vicente Botet wrote:
I was not aware that Boost.Thread was working as a header only library. This was a much-requested feature, so I made sure that boost::mutex at least was usable header-only.
Oh, I remember that now. So would this be fixed or I should switch to lightweight mutex?
As far as Boost.System is not-header-only we can not have both: boost::mutex header-only and compliant with c++11. As said before, I could let the user the possibility to set Boost.Thread to don't use Boost.System via BOOST_THREAD_DONT_USE_SYSTEM. Artyom, Anthony is this satisfactory for you?
That sounds reasonable to me: if people wish to use Boost.Thread header-only then they can define the macro, but anyone who needs to use the full features must link against the library, so can cope with the additional dependency on Boost.System.
It would be great if we could ensure that code with incompatible settings wouldn't link. We could mask out the parts of Boost.Thread that do need the library with that macro, for starters, so we don't need separate builds of the library with and without that macro.
Anthony Hi,
Ihave found that a little patch to Boost.System could make it header-only. It seems that Beman has already tried it, but there are some errors. Here it is the patch device3-1:trunk viboes$ svn diff boost/system libs/system Index: boost/system/error_code.hpp =================================================================== --- boost/system/error_code.hpp (revision 76354) +++ boost/system/error_code.hpp (working copy) @@ -504,7 +504,7 @@ #include <boost/config/abi_suffix.hpp> // pops abi_prefix.hpp pragmas -# ifdef BOOST_ERROR_CODE_HEADER_ONLY +# ifdef BOOST_SYSTEM_INLINED # include <boost/../libs/system/src/error_code.cpp> # endif Index: libs/system/src/error_code.cpp =================================================================== --- libs/system/src/error_code.cpp (revision 76354) +++ libs/system/src/error_code.cpp (working copy) @@ -407,20 +407,20 @@ { # ifndef BOOST_SYSTEM_NO_DEPRECATED - BOOST_SYSTEM_DECL error_code throws; // "throw on error" special error_code; + BOOST_SYSTEM_DECL BOOST_SYSTEM_INLINE error_code throws; // "throw on error" special error_code; // note that it doesn't matter if this // isn't initialized before use since // the only use is to take its // address for comparison purposes # endif - BOOST_SYSTEM_DECL const error_category & system_category() + BOOST_SYSTEM_DECL BOOST_SYSTEM_INLINE const error_category & system_category() { static const system_error_category system_category_const; return system_category_const; } - BOOST_SYSTEM_DECL const error_category & generic_category() + BOOST_SYSTEM_DECL BOOST_SYSTEM_INLINE const error_category & generic_category() { static const generic_error_category generic_category_const; return generic_category_const; Arytom, please could you try the patch to see if this could work for you (define BOOST_SYSTEM_INLINED)? If it is the case, we could see with Beman if he can apply the patch on trunk. Best, Vicente
On 01/21/2012 11:29 PM, Vicente J. Botet Escriba wrote:
Ihave found that a little patch to Boost.System could make it header-only. It seems that Beman has already tried it, but there are some errors. Here it is the patch
device3-1:trunk viboes$ svn diff boost/system libs/system Index: boost/system/error_code.hpp =================================================================== --- boost/system/error_code.hpp (revision 76354) +++ boost/system/error_code.hpp (working copy) @@ -504,7 +504,7 @@
#include <boost/config/abi_suffix.hpp> // pops abi_prefix.hpp pragmas
-# ifdef BOOST_ERROR_CODE_HEADER_ONLY +# ifdef BOOST_SYSTEM_INLINED # include <boost/../libs/system/src/error_code.cpp> # endif
Doesn't that still enable autolink with MSVC?
Le 22/01/12 00:23, Mathias Gaunard a écrit :
On 01/21/2012 11:29 PM, Vicente J. Botet Escriba wrote:
Ihave found that a little patch to Boost.System could make it header-only. It seems that Beman has already tried it, but there are some errors. Here it is the patch
device3-1:trunk viboes$ svn diff boost/system libs/system Index: boost/system/error_code.hpp =================================================================== --- boost/system/error_code.hpp (revision 76354) +++ boost/system/error_code.hpp (working copy) @@ -504,7 +504,7 @@
#include <boost/config/abi_suffix.hpp> // pops abi_prefix.hpp pragmas
-# ifdef BOOST_ERROR_CODE_HEADER_ONLY +# ifdef BOOST_SYSTEM_INLINED # include <boost/../libs/system/src/error_code.cpp> # endif
Doesn't that still enable autolink with MSVC?
I don't think so. I could be missing something, could explain why do you think that? Vicente
On 01/22/2012 12:38 AM, Vicente J. Botet Escriba wrote:
Le 22/01/12 00:23, Mathias Gaunard a écrit :
On 01/21/2012 11:29 PM, Vicente J. Botet Escriba wrote:
Ihave found that a little patch to Boost.System could make it header-only. It seems that Beman has already tried it, but there are some errors. Here it is the patch
device3-1:trunk viboes$ svn diff boost/system libs/system Index: boost/system/error_code.hpp =================================================================== --- boost/system/error_code.hpp (revision 76354) +++ boost/system/error_code.hpp (working copy) @@ -504,7 +504,7 @@
#include <boost/config/abi_suffix.hpp> // pops abi_prefix.hpp pragmas
-# ifdef BOOST_ERROR_CODE_HEADER_ONLY +# ifdef BOOST_SYSTEM_INLINED # include <boost/../libs/system/src/error_code.cpp> # endif
Doesn't that still enable autolink with MSVC?
I don't think so. I could be missing something, could explain why do you think that?
<boost/system/config.hpp> includes <boost/config/auto_link.hpp> regardless or whether BOOST_SYSTEM_INLINED is defined or not.
Le 22/01/12 13:41, Mathias Gaunard a écrit :
On 01/22/2012 12:38 AM, Vicente J. Botet Escriba wrote:
Le 22/01/12 00:23, Mathias Gaunard a écrit :
On 01/21/2012 11:29 PM, Vicente J. Botet Escriba wrote:
Ihave found that a little patch to Boost.System could make it header-only. It seems that Beman has already tried it, but there are some errors. Here it is the patch
device3-1:trunk viboes$ svn diff boost/system libs/system Index: boost/system/error_code.hpp =================================================================== --- boost/system/error_code.hpp (revision 76354) +++ boost/system/error_code.hpp (working copy) @@ -504,7 +504,7 @@
#include <boost/config/abi_suffix.hpp> // pops abi_prefix.hpp pragmas
-# ifdef BOOST_ERROR_CODE_HEADER_ONLY +# ifdef BOOST_SYSTEM_INLINED # include <boost/../libs/system/src/error_code.cpp> # endif
Doesn't that still enable autolink with MSVC?
I don't think so. I could be missing something, could explain why do you think that?
<boost/system/config.hpp> includes <boost/config/auto_link.hpp> regardless or whether BOOST_SYSTEM_INLINED is defined or not.
The code I can see contains #ifdef BOOST_SYSTEM_INLINED #define BOOST_SYSTEM_INLINE inline #define BOOST_SYSTEM_DECL #else #define BOOST_SYSTEM_INLINE ... // // And include the header that does the work: // #include <boost/config/auto_link.hpp> #endif // auto-linking disabled #endif // BOOST_SYSTEM_INLINED The inclusion of boost/config/auto_link.hpp is on the else part, so included only when Boost.System will not be inlined. Vicente
On 01/22/2012 02:01 PM, Vicente J. Botet Escriba wrote:
The inclusion of boost/config/auto_link.hpp is on the else part, so included only when Boost.System will not be inlined.
I thought BOOST_SYSTEM_INLINED was a new macro you were introducing in this patch. So header-only support for Boost.System has always been there, and is not new at all?
On Sat, Jan 21, 2012 at 5:29 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
...
Ihave found that a little patch to Boost.System could make it header-only. It seems that Beman has already tried it, but there are some errors.
I'd like to make Boost.System available for header-only use, but IIRC the suggested changes broke some other libraries that use Boost.System. Also, I'd like to see a Boost guideline worked out for how to make libraries header only without dumping vast numbers of names for operating system headers into the global namespace. --Beman
Le 22/01/12 03:37, Beman Dawes a écrit :
...
Ihave found that a little patch to Boost.System could make it header-only. It seems that Beman has already tried it, but there are some errors. I'd like to make Boost.System available for header-only use, but IIRC
On Sat, Jan 21, 2012 at 5:29 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote: the suggested changes broke some other libraries that use Boost.System. Please, could you point me to which libraries are you referring to? Also, I'd like to see a Boost guideline worked out for how to make libraries header only without dumping vast numbers of names for operating system headers into the global namespace.
I recognize that it could be difficult for libraries as Boost.Thread or Boost.FileSystem, but I don't think Boost.System will be on this case as its dependency are really minor, isn't it? Could you explain more deeply the problem you want to avoid? Best, Vicente
On 01/22/2012 12:00 PM, Vicente J. Botet Escriba wrote:
Le 22/01/12 03:37, Beman Dawes a écrit :
...
Ihave found that a little patch to Boost.System could make it header-only. It seems that Beman has already tried it, but there are some errors. I'd like to make Boost.System available for header-only use, but IIRC
On Sat, Jan 21, 2012 at 5:29 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote: the suggested changes broke some other libraries that use Boost.System. Please, could you point me to which libraries are you referring to? Also, I'd like to see a Boost guideline worked out for how to make libraries header only without dumping vast numbers of names for operating system headers into the global namespace.
I recognize that it could be difficult for libraries as Boost.Thread or Boost.FileSystem, but I don't think Boost.System will be on this case as its dependency are really minor, isn't it? Could you explain more deeply the problem you want to avoid?
error_code.cpp includes windows.h and puts lots of symbol in the global namespace. I'm not sure #include "local_free_on_destruction.hpp" works either in a scenario where the file is included. So there are problems with the approach of including .cpp files as-is, and a better approach must be found.
On Sun, Jan 22, 2012 at 8:29 AM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
On 01/22/2012 12:00 PM, Vicente J. Botet Escriba wrote:
I recognize that it could be difficult for libraries as Boost.Thread or Boost.FileSystem, but I don't think Boost.System will be on this case as its dependency are really minor, isn't it? Could you explain more deeply the problem you want to avoid?
error_code.cpp includes windows.h and puts lots of symbol in the global namespace.
Right. Including windows.h is a non-starter in a header. error_code.cpp also makes extensive use of the unnamed namespace. That's also something that isn't normally permissible in a header.
I'm not sure #include "local_free_on_destruction.hpp" works either in a scenario where the file is included.
Good question. I'm not sure either.
So there are problems with the approach of including .cpp files as-is, and a better approach must be found.
Exactly! --Beman
El 22/01/2012 23:01, Beman Dawes escribió:
Right. Including windows.h is a non-starter in a header.
Boost.DateTime, Thread and Inteprocess have some windows.h predeclarations, but then we have some warnings about C linkage functions: https://svn.boost.org/trac/boost/ticket/6145 It could be a good idea to put some common windows.h predeclarations in a boost::detail file and avoid those warnings. Best, Ion
Le 22/01/12 23:24, Ion Gaztañaga a écrit :
El 22/01/2012 23:01, Beman Dawes escribió:
Right. Including windows.h is a non-starter in a header.
Boost.DateTime, Thread and Inteprocess have some windows.h predeclarations, but then we have some warnings about C linkage functions:
https://svn.boost.org/trac/boost/ticket/6145
It could be a good idea to put some common windows.h predeclarations in a boost::detail file and avoid those warnings.
Boost.Chrono is using the files in boost/detail/win32. Please be free to use them if they are useful to you and complete them as needed. There are some test in libs/chrono/test/win32.cpp. While I made a patch to make Boost.System header-only more than 1 year ago I made use of them. The main issue was what is the expected API when working on cygwin platform. Best, Vicente
Boost.Chrono is using the files in boost/detail/win32. Please be free to use them if they are useful to you and complete them as needed. There are some test in libs/chrono/test/win32.cpp.
Thanks for the hint, I'll have a look.
While I made a patch to make Boost.System header-only more than 1 year ago I made use of them. The main issue was what is the expected API when working on cygwin platform.
I'd say UNIX API. I'm treating cygwin as a UNIX variant in Interprocess. Ion
Le 22/01/12 23:01, Beman Dawes a écrit :
On Sun, Jan 22, 2012 at 8:29 AM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
On 01/22/2012 12:00 PM, Vicente J. Botet Escriba wrote:
I recognize that it could be difficult for libraries as Boost.Thread or Boost.FileSystem, but I don't think Boost.System will be on this case as its dependency are really minor, isn't it? Could you explain more deeply the problem you want to avoid?
error_code.cpp includes windows.h and puts lots of symbol in the global namespace. Right. Including windows.h is a non-starter in a header.
error_code.cpp also makes extensive use of the unnamed namespace. That's also something that isn't normally permissible in a header.
I'm not sure #include "local_free_on_destruction.hpp" works either in a scenario where the file is included. Good question. I'm not sure either.
So there are problems with the approach of including .cpp files as-is, and a better approach must be found. Exactly!
I agree. Please, can you take a look at this thread http://boost.2283326.n4.nabble.com/system-chrono-header-only-libs-tt2992903.... I proposed in it a patch to make Boost.System header-only, and I gues it avoid all these concerns. Best, Vicente
On Sun, Jan 22, 2012 at 6:03 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
... Please, can you take a look at this thread http://boost.2283326.n4.nabble.com/system-chrono-header-only-libs-tt2992903.... I proposed in it a patch to make Boost.System header-only, and I gues it avoid all these concerns.
That thread ends by you saying "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>. " Have you now done that? Did you run into any problems? What testing have you done? --Beman
Beman Dawes wrote
On Sun, Jan 22, 2012 at 6:03 PM, Vicente J. Botet Escriba <vicente.botet@> wrote:
... Please, can you take a look at this thread http://boost.2283326.n4.nabble.com/system-chrono-header-only-libs-tt2992903.... I proposed in it a patch to make Boost.System header-only, and I gues it avoid all these concerns.
That thread ends by you saying "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>. "
This was not the last message. I see one from 06/Jan/2011 on which you say "Vicente Botet's header-only option for Boost.System is mostly working, and will be ready to commit to trunk soon." I don't remember exactly why we didn't do the commit, I need to check the private mails I exchanged with you.
Have you now done that? Did you run into any problems? What testing have you done?
Anyway, the last state I know of is on the sandbox http://svn.boost.org/svn/boost/sandbox/chrono/boost/system/detail/inlined/ and http://svn.boost.org/svn/boost/sandbox/chrono/libs/system/src/ I guess that I run the regression test on Boost.System. Maybe the test should be extended to other libraries using Boost.System. Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/thread-Can-t-use-boost-thread-mutex-hpp-w... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Mon, Jan 23, 2012 at 10:37 AM, Vicente Botet <vicente.botet@wanadoo.fr>wrote:
Beman Dawes wrote
On Sun, Jan 22, 2012 at 6:03 PM, Vicente J. Botet Escriba <vicente.botet@> wrote:
... Please, can you take a look at this thread
http://boost.2283326.n4.nabble.com/system-chrono-header-only-libs-tt2992903.... ?
I proposed in it a patch to make Boost.System header-only, and I gues it avoid all these concerns.
That thread ends by you saying "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>. "
This was not the last message. I see one from 06/Jan/2011 on which you say "Vicente Botet's header-only option for Boost.System is mostly working, and will be ready to commit to trunk soon."
I don't remember exactly why we didn't do the commit, I need to check the private mails I exchanged with you.
Hum... Maybe that's the source of the vague memory I have of a problem with some client library.
Have you now done that? Did you run into any problems? What testing have you done?
Anyway, the last state I know of is on the sandbox
http://svn.boost.org/svn/boost/sandbox/chrono/boost/system/detail/inlined/
and http://svn.boost.org/svn/boost/sandbox/chrono/libs/system/src/
I guess that I run the regression test on Boost.System. Maybe the test should be extended to other libraries using Boost.System.
I'm hesitant to volunteer, with the Kona C++ committee meeting less than two weeks away, but if you send me patches against trunk I'll try them here. --Beman
Beman Dawes wrote
On Mon, Jan 23, 2012 at 10:37 AM, Vicente Botet <vicente.botet@>wrote:
Beman Dawes wrote
On Sun, Jan 22, 2012 at 6:03 PM, Vicente J. Botet Escriba <vicente.botet@> wrote:
... Please, can you take a look at this thread
http://boost.2283326.n4.nabble.com/system-chrono-header-only-libs-tt2992903.... ?
I proposed in it a patch to make Boost.System header-only, and I gues it avoid all these concerns.
That thread ends by you saying "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>. "
This was not the last message. I see one from 06/Jan/2011 on which you say "Vicente Botet's header-only option for Boost.System is mostly working, and will be ready to commit to trunk soon."
I don't remember exactly why we didn't do the commit, I need to check the private mails I exchanged with you.
Hum... Maybe that's the source of the vague memory I have of a problem with some client library.
Have you now done that? Did you run into any problems? What testing have you done?
Anyway, the last state I know of is on the sandbox
http://svn.boost.org/svn/boost/sandbox/chrono/boost/system/detail/inlined/
and http://svn.boost.org/svn/boost/sandbox/chrono/libs/system/src/
I guess that I run the regression test on Boost.System. Maybe the test should be extended to other libraries using Boost.System.
I'm hesitant to volunteer, with the Kona C++ committee meeting less than two weeks away, but if you send me patches against trunk I'll try them here.
Hi, I have created a ticket so that I don't forget again https://svn.boost.org/trac/boost/ticket/6442. The ticket as attached two patches to apply to the boost/system and libs/system directories. I have done some test on a windows machine (Boost.System, Chrono, Thread). I will continue tomorrow with other libraries and platforms. Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/thread-Can-t-use-boost-thread-mutex-hpp-w... Sent from the Boost - Dev mailing list archive at Nabble.com.
on Sun Jan 22 2012, Beman Dawes <bdawes-AT-acm.org> wrote:
On Sun, Jan 22, 2012 at 8:29 AM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
On 01/22/2012 12:00 PM, Vicente J. Botet Escriba wrote:
I recognize that it could be difficult for libraries as Boost.Thread or Boost.FileSystem, but I don't think Boost.System will be on this case as its dependency are really minor, isn't it? Could you explain more deeply the problem you want to avoid?
error_code.cpp includes windows.h and puts lots of symbol in the global namespace.
Right. Including windows.h is a non-starter in a header.
I would rephrase that as, "_forcing_ the inclusion of windows.h in a header is a non-starter." It's not unreasonable to say that if you choose the header-only version of Boost.Filesystem, you have to accept that cost. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
From: Anthony Williams<anthony.ajw@gmail.com> On 18/01/12 14:01, Vicente Botet wrote:
I was not aware that Boost.Thread was working as a header only
From: Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> Le 19/01/12 13:12, Artyom Beilis a écrit : library.
This was a much-requested feature, so I made sure that boost::mutex at least was usable header-only.
Oh, I remember that now. So would this be fixed or I should switch to lightweight mutex?
As far as Boost.System is not-header-only we can not have both: boost::mutex header-only and compliant with c++11. As said before, I could let the user the possibility to set Boost.Thread to don't use Boost.System via BOOST_THREAD_DONT_USE_SYSTEM. Artyom, Anthony is this satisfactory for you?
Best, Vicente
Actually I don't really like using macro BOOST_THREAD_DONT_USE_SYSTEM, unless the boost-thread with and without it are **binary-compatible**. If it can't be done I'd rather prefer that Boost.Thread would require explicit linking. There is already too much problems with Boost ABI. Consider one part of library included <boost/thread/mutex.hpp> with BOOST_THREAD_DONT_USE_SYSTEM and some other without and linked with boost_thread. If this macro makes code binary incompatible it is bad and I don't think it should be used. There are enough problems with Boost API as it is and I don't think we would add more. In this case making lightweight mutexas part of public boost interface would be much better. I don't really care about linking with other library I just wanted to be consistent in my code. That's it. Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/>
Le 22/01/12 12:10, Artyom Beilis a écrit :
From: Anthony Williams<anthony.ajw@gmail.com> On 18/01/12 14:01, Vicente Botet wrote:
I was not aware that Boost.Thread was working as a header only
From: Vicente J. Botet Escriba<vicente.botet@wanadoo.fr> Le 19/01/12 13:12, Artyom Beilis a écrit : library.
This was a much-requested feature, so I made sure that boost::mutex at least was usable header-only.
Oh, I remember that now. So would this be fixed or I should switch to lightweight mutex?
As far as Boost.System is not-header-only we can not have both: boost::mutex header-only and compliant with c++11. As said before, I could let the user the possibility to set Boost.Thread to don't use Boost.System via BOOST_THREAD_DONT_USE_SYSTEM. Artyom, Anthony is this satisfactory for you?
Best, Vicente
Actually I don't really like using macro BOOST_THREAD_DONT_USE_SYSTEM, unless the boost-thread with and without it are **binary-compatible**.
If it can't be done I'd rather prefer that Boost.Thread would require explicit linking.
There is already too much problems with Boost ABI. Consider one part of library included<boost/thread/mutex.hpp> with BOOST_THREAD_DONT_USE_SYSTEM and some other without and linked with boost_thread. If this macro makes code binary incompatible it is bad and I don't think it should be used.
There are enough problems with Boost API as it is and I don't think we would add more.
In this case making lightweight mutexas part of public boost interface would be much better.
I don't really care about linking with other library I just wanted to be consistent in my code. That's it.
You are right. A library should be header-only or not, but not both. Let see if Boost.System could be moved to the set of header-only libraries. If it is not the case, we will see what can be done with lightweight mutexes. On the meantime you will need to link with Boost.System :( Best, Vicente
participants (9)
-
Anthony Williams -
Artyom Beilis -
Beman Dawes -
Dave Abrahams -
Ion Gaztañaga -
Joshua Boyce -
Mathias Gaunard -
Vicente Botet -
Vicente J. Botet Escriba