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

    https://github.com/apache/thrift/pull/469#discussion_r29559168
  
    --- Diff: compiler/cpp/src/generate/t_cpp_generator.cc ---
    @@ -1699,6 +1723,24 @@ void 
t_cpp_generator::generate_struct_ostream_operator(std::ofstream& out, t_str
       out << "}" << endl << endl;
     }
     
    +/**                                                                        
                                                                   
    + * Generates what() method for exceptions                                  
                                                                   
    + */                                                                        
                                                                   
    +void t_cpp_generator::generate_exception_what_method(std::ofstream& out, 
t_struct* tstruct) {
    +  out << indent();
    +  generate_exception_what_method_decl(out, tstruct, true);
    +  out << " {" << endl;
    +
    +  indent_up();
    +
    +  out << indent() << "std::stringstream ss;" << endl;
    +  out << indent() << "ss << \"TException - service has thrown: \" << 
*this;" << endl;
    +  out << indent() << "return ss.str().c_str();" << endl;
    --- End diff --
    
    I think mutable std::string field named texceptionMessageHolder (or even 
longer name) is a good solution - mutable s a keyword so it's not that much a 
trick - we still do not change exception contents, but helper field.
    It seems very unlikely (and quite ugly) for someone to store result of 
what() as a const char* and call what() again... "what()" is usually used for 
logging, and as such is rarely called twice, nor someone stores it direct 
result.
    
    Whenever in doubt - choose std::string over const char* - it's better to 
have handle object to manage memory etc. In very rare situations memory array 
may be better (efficiency, memory consumption etc.) yet it has to be first 
proven to be so.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---

Reply via email to