Update tags
This commit is contained in:
1 parent
b9aebf875e
commit
6d016d732b
1 file changed
+3
-3
+3
-3
@@ -1,7 +1,7 @@
|
||||
*Long term issues*
|
||||
------------------
|
||||
|
||||
* TODO #23: Force MOVE semantic
|
||||
* TODO #23: Force MOVE semantic :ENHANCEMENT:
|
||||
|
||||
Some type may need to have a force MOVE semantic (for example, they can store
|
||||
pointer to themselves). Currently the INIT_MOVE & MOVE operators are more
|
||||
@@ -16,7 +16,7 @@ moving the data before they can be moved using MOVE. Two solutions:
|
||||
- New operator MOVE_SELF to fix a type after it has been moved.
|
||||
- If MOVE defined, force another table and then copy by hand the type. This will be slower and consumme more memory.
|
||||
|
||||
** MOVE in OPLIST
|
||||
** MOVE in OPLIST :ENHANCEMENT:
|
||||
|
||||
Proposal: do not export INIT_MOVE / MOVE operator in OPLIST if the MOVE operator is
|
||||
compatible with a pure COPY semantic. An exported MOVE operator will tell
|
||||
@@ -28,7 +28,7 @@ For example for tuple, it shall
|
||||
- create an init_move operator if no one has disabled INIT_MOVE,
|
||||
- export the init_move operator if at least one has exported a INIT_MOVE and no one has disabled INIT_MOVE.
|
||||
|
||||
|
||||
|
||||
* DONE #22: Enhanced services for SPSC Queue :ENHANCEMENT:
|
||||
|
||||
Add services:
|
||||
|
||||
Reference in new issue
Block a user