73ef4ff3
 Hu Chunming
提交三方库
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
|
[section Rationale]
[heading Decaying Values Captured in YAP Expressions]
The main objective of _yap_ is to be an easy-to-use and easy-to-understand
library for using the _et_ programming technique.
As such, it is very important that the way nodes in a _yap_ expression tree
are represented matches the way nodes in C++ builtin expression are
represented. This keeps the mental model for how to identify and manipulate
parts of expression trees consistent across C++ builtin and _yap_ trees.
Though this creates minor difficulties (for instance, _yap_ terminals cannot
contain arrays), the benefit of a consistent programming model is more
important.
[heading Reference Expressions]
_yap_ expressions can be used as subexpressions to build larger expressions.
_expr_ref_ exists because we want to be able to do this without incurring
unnecessay copies or moves. Consider `v2` and `v3` in this snippet from the
Lazy Vector example. Each is a terminal that owns its value, rather than
referring to it.
lazy_vector v2{{std::vector<double>(4, 2.0)}};
lazy_vector v3{{std::vector<double>(4, 3.0)}};
Now consider this expression:
double d1 = (v2 + v3)[2];
Without using reference semantics, how can we capture this expression, even
before evaluating it, without copying or moving the vectors? We cannot. We
must take references to the `v2` and `v3` subexpressions to avoid copying or
moving.
This comes at a cost. Dealing with _expr_ref_ expressions complicates user
code. The alternatives, silently incurring copies/moves or disallowing the
use of subexpressions to build larger expressions, are worse.
[endsect]
|
