Discussion:
Using C++11/Boost standard synchronization implementations
(too old to reply)
Gruenke,Matt
2017-02-11 21:22:01 UTC
Permalink
Actually, we just got burned by the fact that boost/asio/detail/atomic_count.hpp uses a different implementation for atomic_count in C++03 and C++11. One library had instantiated some Boost.ASIO templates, and was compiled in C++03 mode. When linked with other libraries, also using Boost.ASIO, that were compiled in C++11 mode, the template instantiations from the two got mixed. This resulted in hard-to-find errors, even though they didn’t otherwise call each other.

It seems that, elsewhere in Boost, such issues have been resolved:

https://svn.boost.org/trac/boost/ticket/6779


I think it was a poor choice to vary the binary interface of ASIO, depending on the language standard being used. Boost.ASIO should try to harmonize with the rest of Boost, in this regard.

Looking at boost/asio/detail/config.hpp, I think the following should probably be the default:

BOOST_ASIO_DISABLE_STD_ARRAY
BOOST_ASIO_DISABLE_STD_SHARED_PTR
BOOST_ASIO_DISABLE_STD_ATOMIC
BOOST_ASIO_DISABLE_STD_CHRONO
BOOST_ASIO_DISABLE_STD_FUNCTION
BOOST_ASIO_DISABLE_STD_THREAD
BOOST_ASIO_DISABLE_STD_MUTEX_AND_CONDVAR


People should enable a standard type, only if they have a need to operate on members of those types with other code they have that’s dependent on the standard library versions. Otherwise, it should be safe always to use the Boost versions.


Matt


From: Tatsuyuki Ishi [mailto:***@gmail.com]
Sent: Friday, December 09, 2016 04:47
To: asio-***@lists.sourceforge.net
Subject: [asio-users] Using C++11/Boost standard synchronization implementations

I think it's definitely better to use <thread>, <mutex>, <atomic> or the equivalent functions in Boost instead of a custom implementation.

Some points:
1. They're precompiled system libraries, while asio is commonly used as header-only. Using system libraries also reduce the redundant header inclusions.
2. Less things to manage.
3. std looks better in debugger.

________________________________

This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments.
d***@lecbna.org
2017-02-12 22:05:30 UTC
Permalink
But here I think the mistake is linking binaries compiled with different compiler flags/versions together.
--
Damien Buhl
Software Developer
Post by Gruenke,Matt
Actually, we just got burned by the fact that boost/asio/detail/atomic_count.hpp uses a different implementation for atomic_count in C++03 and C++11. One library had instantiated some Boost.ASIO templates, and was compiled in C++03 mode. When linked with other libraries, also using Boost.ASIO, that were compiled in C++11 mode, the template instantiations from the two got mixed. This resulted in hard-to-find errors, even though they didn’t otherwise call each other.
https://svn.boost.org/trac/boost/ticket/6779
I think it was a poor choice to vary the binary interface of ASIO, depending on the language standard being used. Boost.ASIO should try to harmonize with the rest of Boost, in this regard.
BOOST_ASIO_DISABLE_STD_ARRAY
BOOST_ASIO_DISABLE_STD_SHARED_PTR
BOOST_ASIO_DISABLE_STD_ATOMIC
BOOST_ASIO_DISABLE_STD_CHRONO
BOOST_ASIO_DISABLE_STD_FUNCTION
BOOST_ASIO_DISABLE_STD_THREAD
BOOST_ASIO_DISABLE_STD_MUTEX_AND_CONDVAR
People should enable a standard type, only if they have a need to operate on members of those types with other code they have that’s dependent on the standard library versions. Otherwise, it should be safe always to use the Boost versions.
Matt
Sent: Friday, December 09, 2016 04:47
Subject: [asio-users] Using C++11/Boost standard synchronization implementations
I think it's definitely better to use <thread>, <mutex>, <atomic> or the equivalent functions in Boost instead of a custom implementation.
1. They're precompiled system libraries, while asio is commonly used as header-only. Using system libraries also reduce the redundant header inclusions.
2. Less things to manage.
3. std looks better in debugger.
This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
asio-users mailing list
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio
Gruenke,Matt
2017-02-12 22:36:25 UTC
Permalink
It shouldn’t be necessary to compile all libraries in C++11 or C++03 mode. If you read the bug link I cited, you can see this matches the consensus among boost developers.

If it were a requirement that all C++ libraries, linked or loaded in an executable, be compiled in either C++03 or C++11 mode, then it would make transitioning to C++11 unduly cumbersome (and even impossible, in cases where you’re integrating with a 3rd party library provided in binary form).

Therefore, I consider this a bug, in Boost.ASIO. If others agree, I will file it as such. It turns out it’s been raised on this list, before.


Matt


From: ***@lecbna.org [mailto:***@lecbna.org]
Sent: Sunday, February 12, 2017 17:06
To: asio-***@lists.sourceforge.net
Subject: Re: [asio-users] Using C++11/Boost standard synchronization implementations

But here I think the mistake is linking binaries compiled with different compiler flags/versions together.
--
Damien Buhl
Software Developer

On 11 Feb 2017, at 22:22, Gruenke,Matt <***@Tycoint.com<mailto:***@Tycoint.com>> wrote:
Actually, we just got burned by the fact that boost/asio/detail/atomic_count.hpp uses a different implementation for atomic_count in C++03 and C++11. One library had instantiated some Boost.ASIO templates, and was compiled in C++03 mode. When linked with other libraries, also using Boost.ASIO, that were compiled in C++11 mode, the template instantiations from the two got mixed. This resulted in hard-to-find errors, even though they didn’t otherwise call each other.

It seems that, elsewhere in Boost, such issues have been resolved:

https://svn.boost.org/trac/boost/ticket/6779<https://urldefense.proofpoint.com/v2/url?u=https-3A__svn.boost.org_trac_boost_ticket_6779&d=DwMFaQ&c=0YGvTs3tT-VMy8_v51yLDw&r=VhIBU6ncUQoMafVUqG8TjKbuDohjXo_1oEvOBKGy_DA&m=BcYQDhAMmI3iANVhlNNk1yJyJUaBugVE_rLMf0Pz2Aw&s=oSf71Wxm5tzBxYsA6YEPOzIr2B545ip2rVKqKJVmIZs&e=>


I think it was a poor choice to vary the binary interface of ASIO, depending on the language standard being used. Boost.ASIO should try to harmonize with the rest of Boost, in this regard.

Looking at boost/asio/detail/config.hpp, I think the following should probably be the default:

BOOST_ASIO_DISABLE_STD_ARRAY
BOOST_ASIO_DISABLE_STD_SHARED_PTR
BOOST_ASIO_DISABLE_STD_ATOMIC
BOOST_ASIO_DISABLE_STD_CHRONO
BOOST_ASIO_DISABLE_STD_FUNCTION
BOOST_ASIO_DISABLE_STD_THREAD
BOOST_ASIO_DISABLE_STD_MUTEX_AND_CONDVAR


People should enable a standard type, only if they have a need to operate on members of those types with other code they have that’s dependent on the standard library versions. Otherwise, it should be safe always to use the Boost versions.


Matt


From: Tatsuyuki Ishi [mailto:***@gmail.com]
Sent: Friday, December 09, 2016 04:47
To: asio-***@lists.sourceforge.net<mailto:asio-***@lists.sourceforge.net>
Subject: [asio-users] Using C++11/Boost standard synchronization implementations

I think it's definitely better to use <thread>, <mutex>, <atomic> or the equivalent functions in Boost instead of a custom implementation.

Some points:
1. They're precompiled system libraries, while asio is commonly used as header-only. Using system libraries also reduce the redundant header inclusions.
2. Less things to manage.
3. std looks better in debugger.

________________________________

This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__SlashDot.org&d=DwMFaQ&c=0YGvTs3tT-VMy8_v51yLDw&r=VhIBU6ncUQoMafVUqG8TjKbuDohjXo_1oEvOBKGy_DA&m=BcYQDhAMmI3iANVhlNNk1yJyJUaBugVE_rLMf0Pz2Aw&s=7vYyDa5W920juhnAtgPuomtNyJnqTTdLO6jwAjhF9ug&e=>! http://sdm.link/slashdot<https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdot&d=DwMFaQ&c=0YGvTs3tT-VMy8_v51yLDw&r=VhIBU6ncUQoMafVUqG8TjKbuDohjXo_1oEvOBKGy_DA&m=BcYQDhAMmI3iANVhlNNk1yJyJUaBugVE_rLMf0Pz2Aw&s=mA1AhZcJhAW-NtAwJ9pgR0MMmFrKT75BMSRHALCnM3A&e=>
_______________________________________________
asio-users mailing list
asio-***@lists.sourceforge.net<mailto:asio-***@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/asio-users<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_asio-2Dusers&d=DwMFaQ&c=0YGvTs3tT-VMy8_v51yLDw&r=VhIBU6ncUQoMafVUqG8TjKbuDohjXo_1oEvOBKGy_DA&m=BcYQDhAMmI3iANVhlNNk1yJyJUaBugVE_rLMf0Pz2Aw&s=XlT7bhQqR09-UeUelkzD4b5hGUCfxe2_u1wHm32-R58&e=>
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio<https://urldefense.proofpoint.com/v2/url?u=http-3A__think-2Dasync.com_Asio_WhoIsUsingAsio&d=DwMFaQ&c=0YGvTs3tT-VMy8_v51yLDw&r=VhIBU6ncUQoMafVUqG8TjKbuDohjXo_1oEvOBKGy_DA&m=BcYQDhAMmI3iANVhlNNk1yJyJUaBugVE_rLMf0Pz2Aw&s=gyrqbc07CjaEw-Ag4si3x65UV_eZFhSP-aQ51KyGSGE&e=>

________________________________

This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments.
Loading...