2. Boost Beast Translation (zh_Hans)
3. Doc / Qbk / 08 Design / 1 Http Message (qbk)
4. English
5. Zen

14 string ID 105
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — However, a problem arises. How do we write a function which can accept an object that is either a request or a response? As written, the only obvious solution is to make the message a template type. Additional traits classes would then be needed to make sure that the passed object has a valid type which meets the requirements. These unnecessary complexities are bypassed by making each container a partial specialization: ``` /// An HTTP message template<bool isRequest, class Fields, class Body> struct message; 514/10000 · 514
15 string ID 116
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — /// An HTTP request template<class Fields, class Body> struct message<true, Fields, Body> { 91/10000 · 91
126 string ID 126
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — }; 2/10000 · 2
17 string ID 128
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — /// An HTTP response template<bool isRequest, class Fields, class Body> struct message<false, Fields, Body> { 109/10000 · 109
138 string ID 138
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — }; ``` 6/10000 · 6
19 string ID 141
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Now we can declare a function which takes any message as a parameter: ``` template<bool isRequest, class Fields, class Body> void f(message<isRequest, Fields, Body>& msg); ``` 175/10000 · 175
20 string ID 147
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — This function can manipulate the fields common to requests and responses. If it needs to access the other fields, it can use overloads with partial specialization, or in C++17 a `constexpr` expression: ``` template<bool isRequest, class Fields, class Body> void f(message<isRequest, Fields, Body>& msg) { 304/10000 · 304
21 string ID 162
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — } ``` 5/10000 · 5
22 string ID 165
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Often, in non-trivial HTTP applications, we want to read the HTTP header and examine its contents before choosing a type for [*Body]. To accomplish this, there needs to be a way to model the header portion of a message. And we'd like to do this in a way that allows functions which take the header as a parameter, to also accept a type representing the whole message (the function will see just the header part). This suggests inheritance, by splitting a new base class off of the message: ``` /// An HTTP message header template<bool isRequest, class Fields> struct header; ``` 578/10000 · 578
23 string ID 178
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Code which accesses the fields has to laboriously mention the `fields` member, so we'll not only make `header` a base class but we'll make a quality of life improvement and derive the header from the fields for notational convenience. In order to properly support all forms of construction of [*Fields] there will need to be a set of suitable constructor overloads (not shown): ``` /// An HTTP request header template<class Fields> struct header<true, Fields> : Fields { 470/10000 · 470
192 string ID 192
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — }; 2/10000 · 2
194 string ID 194
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — /// An HTTP response header template<class Fields> struct header<false, Fields> : Fields { 90/10000 · 90
201 string ID 201
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — }; 2/10000 · 2
27 string ID 203
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — /// An HTTP message template<bool isRequest, class Fields, class Body> struct message : header<isRequest, Fields> { 115/10000 · 115
211 string ID 211
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — }; 2/10000 · 2
29 string ID 213
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — ``` 3/10000 · 3
30 string ID 215
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Note that the `message` class now has a constructor allowing messages to be constructed from a similarly typed `header`. This handles the case where the user already has the header and wants to make a commitment to the type for [*Body]. A function can be declared which accepts any header: ``` template<bool isRequest, class Fields> void f(header<isRequest, Fields>& msg); ``` 376/10000 · 376
31 string ID 224
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Until now we have not given significant consideration to the constructors of the `message` class. But to achieve all our goals we will need to make sure that there are enough constructor overloads to not only provide for the special copy and move members if the instantiated types support it, but also allow the fields container and body container to be constructed with arbitrary variadic lists of parameters. This allows the container to fully support allocators. 465/10000 · 465
32 string ID 232
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The solution used in the library is to treat the message like a `std::pair` for the purposes of construction, except that instead of `first` and `second` we have the `Fields` base class and `message::body` member. This means that single-argument constructors for those fields should be accessible as they are with `std::pair`, and that a mechanism identical to the pair's use of `std::piecewise_construct` should be provided. Those constructors are too complex to repeat here, but interested readers can view the declarations in the corresponding header file. 559/10000 · 559
33 string ID 241
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — There is now significant progress with our message container but a stumbling block remains. There is no way to control the allocator for the `std::string` members. We could add an allocator to the template parameter list of the header and message classes, use it for those strings. This is unsatisfying because of the combinatorial explosion of constructor variations needed to support the scheme. It also means that request messages could have [*four] different allocators: two for the fields and body, and two for the method and target strings. A better solution is needed. 575/10000 · 575