thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James E. King, III (JIRA)" <>
Subject [jira] [Commented] (THRIFT-4060) Thrift printTo ostream overload mechanism breaks down when types are nested
Date Sun, 12 Feb 2017 17:29:42 GMT


James E. King, III commented on THRIFT-4060:

In my PR I have already added a compiler argument of {{--gen cpp:no_ostream_operators}} which
someone can use to disable the definition on a file-by-file basis, so using compile time branches
(ifdef) is unnecessary.

We already have language-aware annotations based on the contents of AnnotationTest.thrift,
for example "java:final".  The annotation allows someone the ability to disable it on a structure-by-structure
basis so they can take advantage of the thrift generated operator for things that don't need
special treatment.  What you suggest means if they have one special structure in a thrift
file they want to do their own, they would be forced to move it to a separate thrift file
and include it to leverage this.  It could be done without the annotation option, but I would
like to continue to provide that for flexibility.

I am going to make your suggested test isolation change.

> Thrift printTo ostream overload mechanism breaks down when types are nested
> ---------------------------------------------------------------------------
>                 Key: THRIFT-4060
>                 URL:
>             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 MyLower : public detail::Lower
> {
>     virtual void printTo(std::ostream& os) const override;
> }
> class MyHigher : public detail::Higher
> {
>     virtual void printTo(std::ostream& os) const override
>     {
>         os << lowers;
>         // here's the problem, lowers is a set<detail::Lower> when it serializes
>         // not a set<MyLower>, so I cannot override it...
>     }
> }
> }
> {noformat}
> I'm considering adding an annotation 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 would replace the printTo mechanism that was added in THRIFT-3336.
> Here is an example:
> {noformat}
> namespace cpp example.detail
> struct MyLower {
>    1: binary lowerBinary
> } (cpp.customostream)
> struct MyHigher {
>     1: set<Lower> lowers
> }
> {noformat}
> The annotation {{cpp.customostream}} (or the compiler option {{--gen cpp:no_ostream_operators}}
for global effect) tells the compiler to emit only the declaration of the {{operator <<}}
but does not emit a definition (implementation).  It would be up to the implementation building
against the generated code to provide an operator << if such an operator is needed for
conversion to a stream (cout, lexical_cast to string, etc..).

This message was sent by Atlassian JIRA

View raw message