blob: a3f346bac95369c8876da85954f65e5e41bd28b4 (
plain)
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
|
Interface type for existing composite value types
Some existing value types (e.g., time_period in Boost.DateTime) do not
provide modifiers and the only way to initialize such types is by passing
everything at once in a constructor. For such types it would be nice to
be able to use another, "interface" type to capture the data and then
use it to initialize the desired type at once. The same logic would
apply to persisting the type in the database.
In fact, we already can do this via virtual data members just very
awkwardly -- one has to specify the interface type (as virtual member
type) as well as to/from conversion functions (as accessors and modifiers)
for every data member of the target value type. So it seems pretty
straightforward to allow specifying this once for a type.
We already have a very similar mechanism: extended database type support.
The only difference, really, is that there it is about database types and
here it is about C++ types.
Tricky stuff:
* There can still be accessor/modifier expressions at the element
level (will have to compose the calls).
* Containers could be tricky: for them we require by-reference
access. Yes, containers might not even be supported since we
do simple value and container init in separate functions so
a stack-based temporary won't work. This will probably be ok,
however, since the use-case is to facilittate mapping of existing
composite value types and it is unlikely they will use containers
(or maybe not).
This will need to be implemented as "for all intents and purposes use this
other type as the composite value type except in two places: when getting
const& from the object and when setting value (std::move()?) to the object."
Could this be something that's also useful for simple value types? Yes! Real
use case: custom lazy ptr (implements loading in ->). Being able to use
standard lazy ptr as interface type would be useful. Right now have to go
through virtual data members. Not going to work well for templates though.
|
