[ 
https://issues.apache.org/jira/browse/THRIFT-2471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13977611#comment-13977611
 ] 

Randy Abernethy commented on THRIFT-2471:
-----------------------------------------

I like the shared_ptr approach because:
- it is consistent with the rest of the CPP Thrift API (shared_ptr<protocol>, 
etc.)
- it makes delete a non issue (object hangs around until thrift _and_ user are 
finished with it)
- enables objects to appear multiple times in a  DAG safely (though they will 
be serialized each time)
- Allows the user to send the same objects multiple times in multiple RPC calls 
(no new/delete/copy overhead, just ref up/down)
- Works with async interfaces (we need to have a say in the lifespan of the 
objects if serialization happens out of band, I suspect people needing this 
feature are likely to try passing big stuff which will make async that much 
more important)
- Clearly implies cycles will not be a good thing (I think most know about 
shared_ptr loops)

+1 for starting with DAGs only, offering no de-duplication, and detecting 
cycles in the serializer (and throwing if found)

[~henrique] I agree, weak pointers could be a nice way to do cycles at the type 
level, could then be serialized with the graph<> without touching anything at 
the Protocol level.

> Make cpp.ref annotation language agnostic
> -----------------------------------------
>
>                 Key: THRIFT-2471
>                 URL: https://issues.apache.org/jira/browse/THRIFT-2471
>             Project: Thrift
>          Issue Type: Improvement
>          Components: Compiler (General)
>            Reporter: Jens Geyer
>             Fix For: 0.9.2
>
>
> The proposal is to make the new {{cpp.ref}} annotation introduced with 
> THRIFT-2421 language agnostic instead of a C++ specialty only. 
> The annotation changes inlined nested structs into pointers to structs. This 
> behaviour is potentially relevant with all languages using value semantics 
> for nested structs etc.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to