[asio] Breaking changes committed to cvs HEAD
I have just committed some asio changes to cvs HEAD that will break application code. These changes are part of what's needed to bring the interface into sync with the TR2 proposal. The big change is to the error handling classes, as described below. An async handler of the form: void my_handler(const boost::asio::error& e); becomes: void my_handler(const boost::system::error_code& e); Synchronous error handling like this: boost::asio::error e; sock.connect(ep, boost::asio::assign_error(e)); becomes: boost::system::error_code e; sock.connect(ep, e); And where previously a boost::asio::error exception was thrown, the new exception thrown is boost::system::system_error. Error constants like boost::asio::error::eof stay as they are, i.e.: void my_handler(const boost::system::error_code& e) { if (e == boost::asio::error::eof) { ... } } Programs will now need to link against the boost.system library (which is where boost::system::error_code and boost::system::system_error reside). Once I do a few more TR2-related changes I will post regenerated doxygen documentation to the vault. Stay tuned. Cheers, Chris
Christopher Kohlhoff wrote:
I have just committed some asio changes to cvs HEAD that will break application code. These changes are part of what's needed to bring the interface into sync with the TR2 proposal. The big change is to the error handling classes, as described below.
[snip]
And where previously a boost::asio::error exception was thrown, the new exception thrown is boost::system::system_error.
Error constants like boost::asio::error::eof stay as they are, i.e.:
void my_handler(const boost::system::error_code& e) { if (e == boost::asio::error::eof) { ... } }
Programs will now need to link against the boost.system library (which is where boost::system::error_code and boost::system::system_error reside).
Has Boost.System been reviewed? If not, having a reviewed and accepted library depend on a not-reviewed-and-accepted one seems a bit strange IMHO. // Johan
On 11/8/06, Johan Nilsson <r.johan.nilsson@gmail.com> wrote:
Christopher Kohlhoff wrote:
I have just committed some asio changes to cvs HEAD that will break application code. These changes are part of what's needed to bring the interface into sync with the TR2 proposal. The big change is to the error handling classes, as described below.
[snip]
And where previously a boost::asio::error exception was thrown, the new exception thrown is boost::system::system_error.
Error constants like boost::asio::error::eof stay as they are, i.e.:
void my_handler(const boost::system::error_code& e) { if (e == boost::asio::error::eof) { ... } }
Programs will now need to link against the boost.system library (which is where boost::system::error_code and boost::system::system_error reside).
Has Boost.System been reviewed? If not, having a reviewed and accepted library depend on a not-reviewed-and-accepted one seems a bit strange IMHO.
The stuff in Boost.System was originally part of Boost.Filesystem. It got moved to Boost.System as a result of comments during a mini-review of Boost.Filesystem changes. --Beman
"Beman Dawes" <bdawes@acm.org> skrev i meddelandet news:a61d44020611080925l62b4bfbbpc63c879c41fe5b05@mail.gmail.com...
On 11/8/06, Johan Nilsson <r.johan.nilsson@gmail.com> wrote:
Christopher Kohlhoff wrote:
[snip]
Programs will now need to link against the boost.system library (which is where boost::system::error_code and boost::system::system_error reside).
Has Boost.System been reviewed? If not, having a reviewed and accepted library depend on a not-reviewed-and-accepted one seems a bit strange IMHO.
The stuff in Boost.System was originally part of Boost.Filesystem. It got moved to Boost.System as a result of comments during a mini-review of Boost.Filesystem changes.
I'm trying to find the documentation for the Boost.System stuff - any pointers? / Johan
On 11/8/06, Johan Nilsson <r.johan.nilsson@gmail.com> wrote:
"Beman Dawes" <bdawes@acm.org> skrev i meddelandet news:a61d44020611080925l62b4bfbbpc63c879c41fe5b05@mail.gmail.com...
On 11/8/06, Johan Nilsson <r.johan.nilsson@gmail.com> wrote:
Christopher Kohlhoff wrote:
[snip]
Programs will now need to link against the boost.system library (which is where boost::system::error_code and boost::system::system_error reside).
Has Boost.System been reviewed? If not, having a reviewed and accepted library depend on a not-reviewed-and-accepted one seems a bit strange IMHO.
The stuff in Boost.System was originally part of Boost.Filesystem. It got moved to Boost.System as a result of comments during a mini-review of Boost.Filesystem changes.
I'm trying to find the documentation for the Boost.System stuff - any pointers?
In the CVS Head, see libs/system/doc/error_code.html, and libs/system/doc/system_error.html Also see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2066.html --Beman
Beman Dawes wrote:
On 11/8/06, Johan Nilsson <r.johan.nilsson@gmail.com> wrote:
[snip]
I'm trying to find the documentation for the Boost.System stuff - any pointers?
In the CVS Head, see libs/system/doc/error_code.html, and libs/system/doc/system_error.html
Also see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2066.html
Thanks, I'll take a look at those. / Johan
Johan Nilsson wrote:
Has Boost.System been reviewed? If not, having a reviewed and accepted library depend on a not-reviewed-and-accepted one seems a bit strange IMHO.
I believe it is already an implementation detail of the filesystem library. Now it becomes a shared implementation detail of the asio library as well. I believe the goal of reviewing it as a separate library is to promote a clear publicly documented error handling strategy that can be shared and relied on by many libraries, inside and outside Boost. Once reviewed, I expect that API to become a bit more stable (as in fixed/unchanging) than what is today a library-specific implementation detail. I would also expect both those libraries named above to adopt the new API, especially given the goal of those authors. That said, if boost.system does not pass a review, filesystem and asio still need to handle/report errors and there is no reason they cannot continue using this implementation. There would simply be no mandate to share that API more widely. -- AlisdairM
participants (4)
-
AlisdairM -
Beman Dawes -
Christopher Kohlhoff -
Johan Nilsson