The translation has come to an end.
Exit Zen
12
string ID 63
type: paragraph
English
Here is our first attempt at declaring some message containers:
63/630 · 63
13
string ID 97
type: paragraph
English
These containers are capable of representing everything in the model of HTTP requests and responses described in __rfc7230__. Request and response objects are different types. The user can choose the container used to represent the fields. And the user can choose the [*Body] type, which is a concept defining not only the type of `body` member but also the algorithms used to transfer information in and out of that member when performing serialization and parsing.
466/4660 · 466
14
string ID 105
type: paragraph
English
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/5140 · 514
15
string ID 116
type: paragraph
English
/// An HTTP request template<class Fields, class Body> struct message<true, Fields, Body> {
91/910 · 91
126
string ID 126
type: paragraph
English
};
2/100 · 2
17
string ID 128
type: paragraph
English
/// An HTTP response template<bool isRequest, class Fields, class Body> struct message<false, Fields, Body> {
109/1090 · 109
138
string ID 138
type: paragraph
English
}; ```
6/100 · 6
19
string ID 141
type: paragraph
English
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/1750 · 175
20
string ID 147
type: paragraph
English
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/3040 · 304
21
string ID 162
type: paragraph
English
} ```
5/100 · 5
22
string ID 165
type: paragraph
English
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/5780 · 578
23
string ID 178
type: paragraph
English
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/4700 · 470
192
string ID 192
type: paragraph
English
};
2/100 · 2
194
string ID 194
type: paragraph
English
/// An HTTP response header template<class Fields> struct header<false, Fields> : Fields {
90/900 · 90
201
string ID 201
type: paragraph
English
};
2/100 · 2
27
string ID 203
type: paragraph
English
/// An HTTP message template<bool isRequest, class Fields, class Body> struct message : header<isRequest, Fields> {
115/1150 · 115
211
string ID 211
type: paragraph
English
};
2/100 · 2
29
string ID 213
type: paragraph
English
```
3/100 · 3
30
string ID 215
type: paragraph
English
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/3760 · 376
31
string ID 224
type: paragraph
English
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/4650 · 465