Zen

Translation

type: paragraph
As cpprestsdk is developed by a large corporation, it contains quite a bit of functionality and necessarily has more interfaces. We will break down the interfaces used to model messages into more manageable pieces. This is the container used to store the HTTP header fields: ``` class http_headers { public:
307/3070 · 307

Sign in to save translations.

Key English Chinese (Simplified Han script) Actions
is a library resulting from the 2014 Google Summer of Code. It was submitted for a Boost formal review and rejected in 2015. It is based on Boost.Asio, and development on the library has continued to the present. As of the branch previously linked, it uses these message declarations: ``` template<class Headers, class Body> struct basic_message {
is a library resulting from the 2014 Google Summer of Code. It was submitted for a Boost formal review and rejected in 2015. It is based on Boost.Asio, and development on the library has continued to the present. As of the branch previously linked, it uses these message declarations: ``` template<class Headers, class Body> struct basic_message {
166
private:
private:
170
};
};
typedef basic_message<boost::http::headers, std::vector<std::uint8_t>> message;
typedef basic_message<boost::http::headers, std::vector<std::uint8_t>> message;
template<class Headers, class Body> struct is_message<basic_message<Headers, Body>>: public std::true_type {}; ```
template<class Headers, class Body> struct is_message<basic_message<Headers, Body>>: public std::true_type {}; ```
* This container cannot model a complete message. The ['start-line] items
* This container cannot model a complete message. The ['start-line] items
* `headers_`, `body_`, and `trailers_` may only be default-constructed,
* `headers_`, `body_`, and `trailers_` may only be default-constructed,
* There is no way to defer the commitment of the [*Body] type to after
* There is no way to defer the commitment of the [*Body] type to after
* No stateful allocator support. This follows from the previous limitation
* No stateful allocator support. This follows from the previous limitation
* The trailers are stored in a separate object. Aside from the combinatorial
* The trailers are stored in a separate object. Aside from the combinatorial
* The declarations imply that `std::vector` is a model of [*Body].
* The declarations imply that `std::vector` is a model of [*Body].
* The [*Body] customization point constrains user defined types to
* The [*Body] customization point constrains user defined types to
This representation addresses a narrow range of use cases. It has limited potential for customization and performance. It is more difficult to use because it excludes the start line fields from the model.
This representation addresses a narrow range of use cases. It has limited potential for customization and performance. It is more difficult to use because it excludes the start line fields from the model.
C++ REST SDK (cpprestsdk)
C++ REST SDK (cpprestsdk)
is a Microsoft project which ['"...aims to help C++ developers connect to and interact with services"]. It offers the most functionality of the libraries reviewed here, including support for Websocket services using its websocket++ dependency. It can use native APIs such as HTTP.SYS when building Windows based applications, and it can use Boost.Asio. The WebSocket module uses Boost.Asio exclusively.
is a Microsoft project which ['"...aims to help C++ developers connect to and interact with services"]. It offers the most functionality of the libraries reviewed here, including support for Websocket services using its websocket++ dependency. It can use native APIs such as HTTP.SYS when building Windows based applications, and it can use Boost.Asio. The WebSocket module uses Boost.Asio exclusively.
As cpprestsdk is developed by a large corporation, it contains quite a bit of functionality and necessarily has more interfaces. We will break down the interfaces used to model messages into more manageable pieces. This is the container used to store the HTTP header fields: ``` class http_headers { public:
As cpprestsdk is developed by a large corporation, it contains quite a bit of functionality and necessarily has more interfaces. We will break down the interfaces used to model messages into more manageable pieces. This is the container used to store the HTTP header fields: ``` class http_headers { public:
254
private:
private:
256
}; ```
}; ```
This declaration is quite bare-bones. We note the typical problems of most field containers:
This declaration is quite bare-bones. We note the typical problems of most field containers:
* The container may only be default-constructed.
* The container may only be default-constructed.
* No support for allocators, stateful or otherwise.
* No support for allocators, stateful or otherwise.
* There are no customization points at all.
* There are no customization points at all.
Now we analyze the structure of the larger message container. The library uses a handle/body idiom. There are two public message container interfaces, one for requests (`http_request`) and one for responses (`http_response`). Each interface maintains a private shared pointer to an implementation class. Public member function calls are routed to the internal implementation. This is the first implementation class, which forms the base class for both the request and response implementations: ``` namespace details {
Now we analyze the structure of the larger message container. The library uses a handle/body idiom. There are two public message container interfaces, one for requests (`http_request`) and one for responses (`http_response`). Each interface maintains a private shared pointer to an implementation class. Public member function calls are routed to the internal implementation. This is the first implementation class, which forms the base class for both the request and response implementations: ``` namespace details {
class http_msg_base { public:
class http_msg_base { public:
protected:
protected:
306
}; ```
}; ```
To understand these declarations we need to first understand that cpprestsdk uses the asynchronous model defined by Microsoft's [@https://msdn.microsoft.com/en-us/library/dd504870.aspx [*Concurrency Runtime]]. Identifiers from the [@https://msdn.microsoft.com/en-us/library/jj987780.aspx [*`pplx` namespace]] define common asynchronous patterns such as tasks and events. The `concurrency::streams::istream` parameter and `m_data_available` data member indicates a lack of separation of concerns. The representation of HTTP messages should not be conflated with the asynchronous model used to serialize or parse those messages in the message declarations.
To understand these declarations we need to first understand that cpprestsdk uses the asynchronous model defined by Microsoft's [@https://msdn.microsoft.com/en-us/library/dd504870.aspx [*Concurrency Runtime]]. Identifiers from the [@https://msdn.microsoft.com/en-us/library/jj987780.aspx [*`pplx` namespace]] define common asynchronous patterns such as tasks and events. The `concurrency::streams::istream` parameter and `m_data_available` data member indicates a lack of separation of concerns. The representation of HTTP messages should not be conflated with the asynchronous model used to serialize or parse those messages in the message declarations.
The next declaration forms the complete implementation class referenced by the handle in the public interface (which follows after): ``` /// Internal representation of an HTTP request message. class _http_request final : public http::details::http_msg_base, public std::enable_shared_from_this<_http_request> { public:
The next declaration forms the complete implementation class referenced by the handle in the public interface (which follows after): ``` /// Internal representation of an HTTP request message. class _http_request final : public http::details::http_msg_base, public std::enable_shared_from_this<_http_request> { public:
336
private:
private:
344
};
};
} // namespace details ```
} // namespace details ```
Key English Chinese (Simplified Han script) Actions
protected:
protected:
As cpprestsdk is developed by a large corporation, it contains quite a bit of functionality and necessarily has more interfaces. We will break down the interfaces used to model messages into more manageable pieces. This is the container used to store the HTTP header fields: ``` class http_headers { public:
As cpprestsdk is developed by a large corporation, it contains quite a bit of functionality and necessarily has more interfaces. We will break down the interfaces used to model messages into more manageable pieces. This is the container used to store the HTTP header fields: ``` class http_headers { public:
This declaration is quite bare-bones. We note the typical problems of most field containers:
This declaration is quite bare-bones. We note the typical problems of most field containers:
* The container may only be default-constructed.
* The container may only be default-constructed.
* There are no customization points at all.
* There are no customization points at all.
Tasks in the Concurrency Runtime operate in a fashion similar to `std::future`, but with some improvements such as continuations which are not yet in the C++ standard. The costs of using a task based asynchronous interface instead of completion handlers is well documented: synchronization points along the call chain of composed task operations which cannot be optimized away. See: [@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3747.pdf [*A Universal Model for Asynchronous Operations]] (Kohlhoff).
Tasks in the Concurrency Runtime operate in a fashion similar to `std::future`, but with some improvements such as continuations which are not yet in the C++ standard. The costs of using a task based asynchronous interface instead of completion handlers is well documented: synchronization points along the call chain of composed task operations which cannot be optimized away. See: [@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3747.pdf [*A Universal Model for Asynchronous Operations]] (Kohlhoff).
Now we analyze the structure of the larger message container. The library uses a handle/body idiom. There are two public message container interfaces, one for requests (`http_request`) and one for responses (`http_response`). Each interface maintains a private shared pointer to an implementation class. Public member function calls are routed to the internal implementation. This is the first implementation class, which forms the base class for both the request and response implementations: ``` namespace details {
Now we analyze the structure of the larger message container. The library uses a handle/body idiom. There are two public message container interfaces, one for requests (`http_request`) and one for responses (`http_response`). Each interface maintains a private shared pointer to an implementation class. Public member function calls are routed to the internal implementation. This is the first implementation class, which forms the base class for both the request and response implementations: ``` namespace details {
class http_msg_base { public:
class http_msg_base { public:
The design of the message container in this library is cumbersome with its system of customization using trait specializations. The use of these customizations is extremely limited due to the way they are used in the container declaration, making the design overly complex without corresponding benefit.
The design of the message container in this library is cumbersome with its system of customization using trait specializations. The use of these customizations is extremely limited due to the way they are used in the container declaration, making the design overly complex without corresponding benefit.
Boost.HTTP
Boost.HTTP
is a library resulting from the 2014 Google Summer of Code. It was submitted for a Boost formal review and rejected in 2015. It is based on Boost.Asio, and development on the library has continued to the present. As of the branch previously linked, it uses these message declarations: ``` template<class Headers, class Body> struct basic_message {
is a library resulting from the 2014 Google Summer of Code. It was submitted for a Boost formal review and rejected in 2015. It is based on Boost.Asio, and development on the library has continued to the present. As of the branch previously linked, it uses these message declarations: ``` template<class Headers, class Body> struct basic_message {
typedef basic_message<boost::http::headers, std::vector<std::uint8_t>> message;
typedef basic_message<boost::http::headers, std::vector<std::uint8_t>> message;
template<class Headers, class Body> struct is_message<basic_message<Headers, Body>>: public std::true_type {}; ```
template<class Headers, class Body> struct is_message<basic_message<Headers, Body>>: public std::true_type {}; ```
* This container cannot model a complete message. The ['start-line] items
* This container cannot model a complete message. The ['start-line] items
* `headers_`, `body_`, and `trailers_` may only be default-constructed,
* `headers_`, `body_`, and `trailers_` may only be default-constructed,
* There is no way to defer the commitment of the [*Body] type to after
* There is no way to defer the commitment of the [*Body] type to after
* No stateful allocator support. This follows from the previous limitation
* No stateful allocator support. This follows from the previous limitation
* The trailers are stored in a separate object. Aside from the combinatorial
* The trailers are stored in a separate object. Aside from the combinatorial
* The declarations imply that `std::vector` is a model of [*Body].
* The declarations imply that `std::vector` is a model of [*Body].
* The [*Body] customization point constrains user defined types to
* The [*Body] customization point constrains user defined types to
This representation addresses a narrow range of use cases. It has limited potential for customization and performance. It is more difficult to use because it excludes the start line fields from the model.
This representation addresses a narrow range of use cases. It has limited potential for customization and performance. It is more difficult to use because it excludes the start line fields from the model.
C++ REST SDK (cpprestsdk)
C++ REST SDK (cpprestsdk)
is a Microsoft project which ['"...aims to help C++ developers connect to and interact with services"]. It offers the most functionality of the libraries reviewed here, including support for Websocket services using its websocket++ dependency. It can use native APIs such as HTTP.SYS when building Windows based applications, and it can use Boost.Asio. The WebSocket module uses Boost.Asio exclusively.
is a Microsoft project which ['"...aims to help C++ developers connect to and interact with services"]. It offers the most functionality of the libraries reviewed here, including support for Websocket services using its websocket++ dependency. It can use native APIs such as HTTP.SYS when building Windows based applications, and it can use Boost.Asio. The WebSocket module uses Boost.Asio exclusively.
166
private:
private:
170
};
};
254
private:
private:
256
}; ```
}; ```
306
}; ```
}; ```
336
private:
private:
344
};
};

Loading…

User avatar admin

String added in the repository
As cpprestsdk is developed by a large corporation, it contains quite a bit of functionality and necessarily has more interfaces. We will break down the interfaces used to model messages into more manageable pieces. This is the container used to store the HTTP header fields: ``` class http_headers { public:
As cpprestsdk is developed by a large corporation, it contains quite a bit of functionality and necessarily has more interfaces. We will break down the interfaces used to model messages into more manageable pieces. This is the container used to store the HTTP header fields: ``` class http_headers { public:
06/05/2026
Browse all string changes

Things to check

Unchanged translation

Source and translation are identical.

Reset

Glossary

English Chinese (Simplified Han script)
No related strings found in the glossary.

String information

Source string description
type: paragraph
Unit identifier
58653
Source string location
string ID 244
String age
06/05/2026
Last updated
06/05/2026
Source string age
06/05/2026
Translation file QuickBook file
doc/qbk/08_design/2_http_comparison_zh_Hans.qbk, string 38