[boost] [thread] Can't use boost/thread/mutex.hpp without boost

Artyom Beilis

unread,

Jan 18, 2012, 6:13:50 AM1/18/12

to Boost

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/

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Vicente Botet

unread,

Jan 18, 2012, 9:01:24 AM1/18/12

to bo...@lists.boost.org

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-without-boost-system-tp4306342p4306708.html
Sent from the Boost - Dev mailing list archive at Nabble.com.

Artyom Beilis

unread,

Jan 18, 2012, 9:09:01 AM1/18/12

to bo...@lists.boost.org

>>

>> 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

Vicente J. Botet Escriba

unread,

Jan 18, 2012, 4:22:42 PM1/18/12

to bo...@lists.boost.org

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

Joshua Boyce

unread,

Jan 18, 2012, 10:37:53 PM1/18/12

to bo...@lists.boost.org

On Thu, Jan 19, 2012 at 8:22 AM, Vicente J. Botet Escriba <
vicent...@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.

Artyom Beilis

unread,

Jan 19, 2012, 3:59:34 AM1/19/12

to bo...@lists.boost.org

> From: Vicente J. Botet Escriba <vicent...@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

Anthony Williams

unread,

Jan 19, 2012, 4:31:12 AM1/19/12

to bo...@lists.boost.org

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

Artyom Beilis

unread,

Jan 19, 2012, 7:12:43 AM1/19/12

to bo...@lists.boost.org

----- Original Message -----
> From: Anthony Williams <antho...@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

Vicente J. Botet Escriba

unread,

Jan 19, 2012, 4:39:10 PM1/19/12

to bo...@lists.boost.org

Le 19/01/12 13:12, Artyom Beilis a écrit :

> ----- Original Message -----
>> From: Anthony Williams<antho...@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

Anthony Williams

unread,

Jan 20, 2012, 2:42:28 AM1/20/12

to bo...@lists.boost.org

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<antho...@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

_______________________________________________

Vicente J. Botet Escriba

unread,

Jan 21, 2012, 5:29:34 PM1/21/12

to bo...@lists.boost.org

Le 20/01/12 08:42, Anthony Williams a écrit :

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

Mathias Gaunard

unread,

Jan 21, 2012, 6:23:33 PM1/21/12

to bo...@lists.boost.org

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?

Vicente J. Botet Escriba

unread,

Jan 21, 2012, 6:38:00 PM1/21/12

to bo...@lists.boost.org

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

Beman Dawes

unread,

Jan 21, 2012, 9:37:12 PM1/21/12

to bo...@lists.boost.org

On Sat, Jan 21, 2012 at 5:29 PM, Vicente J. Botet Escriba
<vicent...@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

Vicente J. Botet Escriba

unread,

Jan 22, 2012, 6:00:25 AM1/22/12

to bo...@lists.boost.org

Le 22/01/12 03:37, Beman Dawes a écrit :

> On Sat, Jan 21, 2012 at 5:29 PM, Vicente J. Botet Escriba
> <vicent...@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.

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

Artyom Beilis

unread,

Jan 22, 2012, 6:10:04 AM1/22/12

to bo...@lists.boost.org

> From: Vicente J. Botet Escriba <vicent...@wanadoo.fr>

> Le 19/01/12 13:12, Artyom Beilis a écrit :

>>> From: Anthony Williams<antho...@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
>
>

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/>

_______________________________________________

Vicente J. Botet Escriba

unread,

Jan 22, 2012, 6:25:58 AM1/22/12

to bo...@lists.boost.org

Le 22/01/12 12:10, Artyom Beilis a écrit :

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

Mathias Gaunard

unread,

Jan 22, 2012, 7:41:40 AM1/22/12

to bo...@lists.boost.org

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.

Vicente J. Botet Escriba

unread,

Jan 22, 2012, 8:01:25 AM1/22/12

to bo...@lists.boost.org

Le 22/01/12 13:41, Mathias Gaunard a écrit :

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

Mathias Gaunard

unread,

Jan 22, 2012, 8:23:07 AM1/22/12

to bo...@lists.boost.org

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?

Mathias Gaunard

unread,

Jan 22, 2012, 8:29:15 AM1/22/12

to bo...@lists.boost.org

On 01/22/2012 12:00 PM, Vicente J. Botet Escriba wrote:
> Le 22/01/12 03:37, Beman Dawes a écrit :
>> On Sat, Jan 21, 2012 at 5:29 PM, Vicente J. Botet Escriba
>> <vicent...@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.
> 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.

Beman Dawes

unread,

Jan 22, 2012, 5:01:56 PM1/22/12

to bo...@lists.boost.org

On Sun, Jan 22, 2012 at 8:29 AM, Mathias Gaunard
<mathias...@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

Ion Gaztañaga

unread,

Jan 22, 2012, 5:24:34 PM1/22/12

to bo...@lists.boost.org

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

Vicente J. Botet Escriba

unread,

Jan 22, 2012, 5:57:19 PM1/22/12

to bo...@lists.boost.org

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

Vicente J. Botet Escriba

unread,

Jan 22, 2012, 6:03:17 PM1/22/12

to bo...@lists.boost.org

Le 22/01/12 23:01, Beman Dawes a écrit :

> On Sun, Jan 22, 2012 at 8:29 AM, Mathias Gaunard
> <mathias...@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.html?
I proposed in it a patch to make Boost.System header-only, and I gues it
avoid all these concerns.

Best,
Vicente

Beman Dawes

unread,

Jan 23, 2012, 9:23:37 AM1/23/12

to bo...@lists.boost.org

On Sun, Jan 22, 2012 at 6:03 PM, Vicente J. Botet Escriba
<vicent...@wanadoo.fr> wrote:
>... Please, can you take a look at this thread

> http://boost.2283326.n4.nabble.com/system-chrono-header-only-libs-tt2992903.html?
> 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

Vicente Botet

unread,

Jan 23, 2012, 10:37:24 AM1/23/12

to bo...@lists.boost.org

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.html?
>> 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-without-boost-system-tp4306342p4321038.html

Sent from the Boost - Dev mailing list archive at Nabble.com.

_______________________________________________

Beman Dawes

unread,

Jan 23, 2012, 3:00:43 PM1/23/12

to bo...@lists.boost.org

On Mon, Jan 23, 2012 at 10:37 AM, Vicente Botet <vicent...@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.html
> ?
> >> 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

Ion Gaztañaga

unread,

Jan 23, 2012, 4:02:07 PM1/23/12

to bo...@lists.boost.org

> 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

Vicente Botet

unread,

Jan 23, 2012, 6:56:05 PM1/23/12

to bo...@lists.boost.org

Beman Dawes wrote

>
> On Mon, Jan 23, 2012 at 10:37 AM, Vicente Botet

> <vicente.botet@>wrote:

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-without-boost-system-tp4306342p4322498.html

Sent from the Boost - Dev mailing list archive at Nabble.com.

_______________________________________________

Dave Abrahams

unread,

Jan 30, 2012, 1:29:57 PM1/30/12

to bo...@lists.boost.org

on Sun Jan 22 2012, Beman Dawes <bdawes-AT-acm.org> wrote:

> On Sun, Jan 22, 2012 at 8:29 AM, Mathias Gaunard
> <mathias...@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

Reply all

Reply to author

Forward

[boost] [thread] Can't use boost/thread/mutex.hpp without boost_system

Artyom Beilis

Vicente Botet

Artyom Beilis

Vicente J. Botet Escriba

Joshua Boyce

Artyom Beilis

Anthony Williams

Artyom Beilis

Vicente J. Botet Escriba

Anthony Williams

Vicente J. Botet Escriba

Mathias Gaunard

Vicente J. Botet Escriba

Beman Dawes

Vicente J. Botet Escriba

Artyom Beilis

Vicente J. Botet Escriba

Mathias Gaunard

Vicente J. Botet Escriba

Mathias Gaunard

Mathias Gaunard

Beman Dawes

Ion Gaztañaga

Vicente J. Botet Escriba

Vicente J. Botet Escriba

Beman Dawes

Vicente Botet

Beman Dawes

Ion Gaztañaga

Vicente Botet

Dave Abrahams