Uploaded image for project: 'Thrift'
  1. Thrift
  2. THRIFT-4060

Thrift printTo ostream overload mechanism breaks down when types are nested

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 0.9.3, 0.10.0
    • Fix Version/s: 0.11.0
    • Component/s: C++ - Compiler
    • Labels:
      None
    • Environment:

      Ubuntu 14.04 LTS

      Description

      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:

      Thrift

      namespace cpp example.detail
      
      struct Lower {
         1: binary lowerBinary
      }
      
      struct Higher {
          1: set<Lower> lowers
      }
      

      C++

      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 in,
              // not a set<MyLower>, so I cannot override it...
          }
      }
      
      }
      

      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:

      namespace cpp example.detail
      
      struct MyLower {
         1: binary lowerBinary
      } (cpp.customostream)
      
      struct MyHigher {
          1: set<Lower> lowers
      }
      

      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..).

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                jking3 James E. King III
                Reporter:
                jking3 James E. King III
              • Votes:
                1 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: