[interprocess] why not use boost/system/error_code?
Hi, Is there any reason to have an own error code wrapper in boost::interprocess/errors.hpp, instead of using boost::system::error_code? Cheers, Christian
On 25/11/2010 6:39, Christian Holmquist wrote:
Hi,
Is there any reason to have an own error code wrapper in boost::interprocess/errors.hpp, instead of using boost::system::error_code?
Because interprocess was developed before system. There is plan to adapt it in the future, but we need to maintain some backwards compatibility. Best, Ion
2010/11/25 Ion Gaztañaga <igaztanaga@gmail.com>:
On 25/11/2010 6:39, Christian Holmquist wrote:
Hi,
Is there any reason to have an own error code wrapper in boost::interprocess/errors.hpp, instead of using boost::system::error_code?
Because interprocess was developed before system. There is plan to adapt it in the future, but we need to maintain some backwards compatibility.
Also, the final C++0x standard is due to be voted out in mid-March, and Boost.System in effect becomes part of the standard library. While there won't be much change in the WP between now and March, a few details may well change. My plan is to do a pass through Boost.System then, and bring it as close to the standard as possible, including ifdef use of C++0x features. After that might be the best time for Ion and other Boost developers thinking about changing code to use Boost.System. --Beman
On 26/11/2010 1:28, Beman Dawes wrote:
2010/11/25 Ion Gaztañaga<igaztanaga@gmail.com>:
On 25/11/2010 6:39, Christian Holmquist wrote:
Hi,
Is there any reason to have an own error code wrapper in boost::interprocess/errors.hpp, instead of using boost::system::error_code?
Because interprocess was developed before system. There is plan to adapt it in the future, but we need to maintain some backwards compatibility.
Also, the final C++0x standard is due to be voted out in mid-March, and Boost.System in effect becomes part of the standard library. While there won't be much change in the WP between now and March, a few details may well change. My plan is to do a pass through Boost.System then, and bring it as close to the standard as possible, including ifdef use of C++0x features. After that might be the best time for Ion and other Boost developers thinking about changing code to use Boost.System.
Thanks Beman. At that time, I think I will need some guidelines to know which errors should be redirected to Boost.System exceptions and which should be thrown as library errors. For instance, a shared memory could be implemented as mapped files in some systems and with native shared memory in others, but an Interprocess user might want to have some unified error system to maintain portability. I guess Filesystem and Asio have already paved the way. Ion
participants (3)
-
Beman Dawes -
Christian Holmquist -
Ion Gaztañaga