[ https://issues.apache.org/jira/browse/THRIFT-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848469#comment-15848469 ]
ASF GitHub Bot commented on THRIFT-4060: ---------------------------------------- Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1172 So job #2 failed strangely in c_glib which is unrelated to this change. I pushed an empty change to kick a rebuild. I expect it to clear... Here's the job that failed: https://travis-ci.org/apache/thrift/jobs/197100291 > Thrift printTo ostream overload mechanism breaks down when types are nested > --------------------------------------------------------------------------- > > Key: THRIFT-4060 > URL: https://issues.apache.org/jira/browse/THRIFT-4060 > Project: Thrift > Issue Type: Bug > Components: C++ - Compiler > Affects Versions: 0.9.3, 0.10.0 > Environment: Ubuntu 14.04 LTS > Reporter: James E. King, III > Assignee: James E. King, III > > I'm in the middle of converting a project that provides some ostream > operators (for logging purposes) for a number of thrift structures. The > project was using 0.8.0 and in 0.9.3 some ostream operator overloads were > added with THRIFT-3336. The solution that was provided here runs into > complications if a thrift structure is contained within another one. Take > this simple example: > h4. Thrift > {noformat} > namespace cpp example.detail > struct Lower { > 1: binary lowerBinary > } > struct Higher { > 1: set<Lower> lowers > } > {noformat} > h4. C++ > {noformat} > namespace example { > class Lower : public detail::Lower > { > virtual void printTo(std::ostream& os) const override; > } > class Higher : public detail::Higher > { > virtual void printTo(std::ostream& os) const override > { > os << lowers; // WHOOPS! > // I cannot say os << lowers, since lowers is an example::detail > concept > // it will print the thrift operator output here > } > } > } > {noformat} > I'm considering adding an anotation to the thrift IDL that the compiler will > recognize that allows someone to say, "I am going to provide my own > operator<< for this structure, don't generate one". > This will allow existing projects with this issue to maintain compatibility > without major refactoring. Here is an example: > {noformat} > namespace cpp example.detail > struct Lower { > 1: binary lowerBinary > } (cpp.customostream) > struct Higher { > 1: set<Lower> lowers > } > {noformat} > For Lower, this would omit any operator << by the compiler, and thus also > would not emit a printTo override for Lower. It would be up to the > implementation building against the generated code to provide an operator <<. -- This message was sent by Atlassian JIRA (v6.3.15#6346)