Updated documentation.

git-svn-id: http://svn.boost.org/svn/boost/trunk@84362 b8fc166d-592f-0410-95f2-cb63ce0dd405
Add generic socket protocols and converting move constructors.

Four new protocol classes have been added:

- asio::generic::datagram_protocol
- asio::generic::raw_protocol
- asio::generic::seq_packet_protocol
- asio::generic::stream_protocol

These classes implement the Protocol type requirements, but allow the
user to specify the address family (e.g. AF_INET) and protocol type
(e.g. IPPROTO_TCP) at runtime.

A new endpoint class template, asio::generic::basic_endpoint, has been
added to support these new protocol classes. This endpoint can hold any
other endpoint type, provided its native representation fits into a
sockaddr_storage object.

When using C++11, it is now possible to perform move construction from a
socket (or acceptor) object to convert to the more generic protocol's
socket (or acceptor) type. If the protocol conversion is valid:

  Protocol1 p1 = ...;
  Protocol2 p2(p1);

then the corresponding socket conversion is allowed:

  Protocol1::socket socket1(io_service);
  ...
  Protocol2::socket socket2(std::move(socket1));

For example, one possible conversion is from a TCP socket to a generic
stream-oriented socket:

  asio::ip::tcp::socket socket1(io_service);
  ...
  asio::generic::stream_protocol::socket socket2(std::move(socket1));

The conversion is also available for move-assignment. Note that these
conversions are not limited to the newly added generic protocol classes.
User-defined protocols may take advantage of this feature by similarly
ensuring the conversion from Protocol1 to Protocol2 is valid, as above.

As a convenience, the socket acceptor's accept() and async_accept()
functions have been changed so that they can directly accept into a
different protocol's socket type, provided the protocol conversion is
valid. For example, the following is now possible:

  asio::ip::tcp::acceptor acceptor(io_service);
  ...
  asio::generic::stream_protocol::socket socket1(io_service);
  acceptor.accept(socket1);


git-svn-id: http://svn.boost.org/svn/boost/trunk@84363 b8fc166d-592f-0410-95f2-cb63ce0dd405
Manifest is now always generated for MSVC 8 and later. This is needed in order to solve problems with Windows UAC requiring elevated priviledges for some tests that have 'patch' in their names.

git-svn-id: http://svn.boost.org/svn/boost/trunk@84370 b8fc166d-592f-0410-95f2-cb63ce0dd405
When a {} repeat sequence is invalid or incomplete, and the language is Perl, then backtrack and treat the sequence as a literal, not a repeat operator.
Fixes #8569.

git-svn-id: http://svn.boost.org/svn/boost/trunk@84371 b8fc166d-592f-0410-95f2-cb63ce0dd405
Add conditional `noexcept` for move constructors.

Also added `noexcept` for destructors because of a gcc bug, see:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56191

Found via:

http://stackoverflow.com/questions/15721544/destructors-and-noexcept

git-svn-id: http://svn.boost.org/svn/boost/trunk@84373 b8fc166d-592f-0410-95f2-cb63ce0dd405
Add `noexcept` annotations to iterators.

I couldn't find any sepecification in the standard, but I'd assume that since
`begin` and `end` are both `noexcept`, the iterator copy constructors must be.

To justify adding `noexcept` to these members, see 17.6.3.5 (part of the
allocator requirements) of n3485, which says about allocator's pointer types,
"No constructor, comparison operator, copy operation, move operation, or swap
operation on these types shall exit via an exception."

Not relevant in this case but allocator pointers also need to model
NullablePointer. From 17.6.3.3, "No operation which is part of the
NullablePointer requirements shall exit via an exception."

git-svn-id: http://svn.boost.org/svn/boost/trunk@84374 b8fc166d-592f-0410-95f2-cb63ce0dd405
Fill in more missing quickbook test copyright info.

git-svn-id: http://svn.boost.org/svn/boost/trunk@84376 b8fc166d-592f-0410-95f2-cb63ce0dd405