[tr2][filesystem][asio] header <boost/system_error.hpp> roadmap?
The Filesystem proposal accepted by the C++ committee's LWG for TR2 includes components for reporting system errors from library functions that depend on operating system API's. There are error_code and system_error classes, four free functions, etc. They will go in a TR2 header named <system_error>. Presumably for Boost it will be called <boost/system_error.hpp> or similar. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1975.html#Diagnosti... Boost.Filesystem is the first Boost library to use <boost/system_error.hpp>. Chris Kohlhoff is planning to use it in asio, and has suggested improvements that I'll incorporate. Presumably the header will be used by other Boost libraries in the future. What should the roadmap be for moving this header into Boost? Should it be a separate library? Seems smallish for that. Does it need a formal review? A mini-review? Is it OK if I put in CVS now in boost/detail? Opinions? --Beman
Beman Dawes <bdawes@acm.org> writes:
The Filesystem proposal accepted by the C++ committee's LWG for TR2 includes components for reporting system errors from library functions that depend on operating system API's. There are error_code and system_error classes, four free functions, etc. They will go in a TR2 header named <system_error>. Presumably for Boost it will be called <boost/system_error.hpp> or similar.
See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1975.html#Diagnosti...
Boost.Filesystem is the first Boost library to use <boost/system_error.hpp>. Chris Kohlhoff is planning to use it in asio, and has suggested improvements that I'll incorporate. Presumably the header will be used by other Boost libraries in the future.
What should the roadmap be for moving this header into Boost?
Should it be a separate library? Seems smallish for that.
Does it need a formal review? A mini-review?
Is it OK if I put in CVS now in boost/detail?
Opinions?
As long as it is an implementation detail of other libraries, it can live in boost/detail. If it's to be a public interface, it should get a review (mini, IMO). -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> wrote:
Beman Dawes <bdawes@acm.org> writes:
What should the roadmap be for moving this header into Boost?
Should it be a separate library? Seems smallish for that.
Does it need a formal review? A mini-review?
Is it OK if I put in CVS now in boost/detail?
Opinions?
As long as it is an implementation detail of other libraries, it can live in boost/detail. If it's to be a public interface, it should get a review (mini, IMO).
The types would be definitely part of the public interface of asio at least (i.e. error_code parameters on sync functions and callback function objects), so I guess that would mean a review. Is it feasible to get a review done in time for including this stuff in 1.35? I want to avoid changing the asio public interface after it goes out in a boost release, and switching error types is likely to be a breaking change. Cheers, Chris
participants (3)
-
Beman Dawes -
Christopher Kohlhoff -
David Abrahams