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

ASF GitHub Bot commented on THRIFT-4060:
----------------------------------------

Github user jeking3 commented on a diff in the pull request:

    https://github.com/apache/thrift/pull/1172#discussion_r100707345
  
    --- Diff: lib/cpp/test/AnnotationTest.cpp ---
    @@ -0,0 +1,73 @@
    +/*
    + * Licensed to the Apache Software Foundation (ASF) under one
    + * or more contributor license agreements. See the NOTICE file
    + * distributed with this work for additional information
    + * regarding copyright ownership. The ASF licenses this file
    + * to you under the Apache License, Version 2.0 (the
    + * "License"); you may not use this file except in compliance
    + * with the License. You may obtain a copy of the License at
    + *
    + *   http://www.apache.org/licenses/LICENSE-2.0
    + *
    + * Unless required by applicable law or agreed to in writing,
    + * software distributed under the License is distributed on an
    + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
    + * KIND, either express or implied. See the License for the
    + * specific language governing permissions and limitations
    + * under the License.
    + */
    +#define BOOST_TEST_MODULE AnnotationTest
    +#include <boost/test/unit_test.hpp>
    +#include "gen-cpp/AnnotationTest_types.h"
    +#include <ostream>
    +#include <sstream>
    +
    +// Normally thrift generates ostream operators, however
    +// with the annotation "cpp.customostream" one can tell the
    +// compiler they are going to provide their own, and not
    +// emit operator << or printTo().
    +
    +std::ostream& operator<<(std::ostream& os, const ostr_custom& osc)
    +{
    +  os << "{ bar = " << osc.bar << "; }";
    +  return os;
    +}
    +
    +BOOST_AUTO_TEST_SUITE(BOOST_TEST_MODULE)
    +
    +BOOST_AUTO_TEST_CASE(test_cpp_customostream) {
    +  //
    +  // Show the compiler generated ostream operator does something..
    +  //
    +
    +  ostr_default def;
    +  def.__set_bar(10);
    +
    +  std::stringstream ssd;
    +  ssd << def;
    +  BOOST_CHECK_EQUAL(ssd.str(), "ostr_default(bar=10)");
    +
    +  //
    +  // Now show that if cpp.customostream is added as an annotation,
    +  // the behavior can be overridden in a safe and usable way (THRIFT-4060).
    +  //
    +
    +  ostr_custom cus;
    +  cus.__set_bar(10);
    +
    +  std::stringstream csd;
    +  csd << cus;
    +  BOOST_CHECK_EQUAL(csd.str(), "{ bar = 10; }");
    --- End diff --
    
    I split it out into two tests without comments.


> 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 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...
>     }
> }
> }
> {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
(v6.3.15#6346)

Reply via email to