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

Randy Abernethy commented on THRIFT-1753:
-----------------------------------------

Thanks for the thoughts, a great digest of the issues. I took a deeper look at 
the thrift C++ dependencies and what it would take to have a dependency free 
thrift for most straight forward C++11 user oriented RPC development.

C++ compiler code generator changes seem pretty mild at first blush, I noted 
only boost::shared_ptr and boost::dynamic_pointer_cast in the source. 

The lib/cpp/src based boost:: dependencies are a little more involved:

Some conversions would be straight forward:
•       boost::thread =>  std::thread
•       boost::this_thread  =>  std::this_thread
•       boost::timed_mutex  =>  std::timed_mutex
•       boost::adopt_lock  =>  std::adopt_lock
•       boost::shared_ptr  =>  std::shared_ptr
•       boost::weak_ptr  =>  std::weak_ptr
•       boost::dynamic_pointer_cast  => std::dynamic_pointer_cast  
•       boost::bind  => std::bind
•       boost::call_once  =>  std::call_once
•       boost::once_flag  =>  std::once_flag
•       boost::enable_if  =>  std::enable_if
•       boost::is_convertible  =>  std::is_convertible
•       boost::condition_variable_any  =>  std::condition_variable_any

Some conversions are clear but not as simple as “thrift::”  =>  “boost::” or 
“std::”:
•       boost::scoped_ptr  =>  std::unique_ptr
•       boost::scoped_array  =>  std::unique_ptr
•       boost::lexical_cast  =>  std::to_string(), std::stod(), std::stoi(), 
etc.
•       boost::bad_lexical_cast  =>  thrift:: bad_lexical_cast (or whatever)
•       boost::posix_time  =>  std::chrono
•       boost::get_system_time  =>  std::chrono
•       boost::iends_with  =>  std::string::compare
•       boost::istarts_with  =>  std::string::compare
•       boost::noncopyable  =>  A( const A&) = delete;  A& operator=(const A&) 
= delete

Some can be sourced from stdint.h:
•       boost::int64_t    
•       boost::uint32_t  
•       boost::uint8_t   

Other boost dependencies might require a little rewrite:
•       boost::char_separator
•       boost::tokenizer

>From a thrift adoption stand point, I do think it would be nice if C++11 users 
>could install basic user style thrift support free of dependencies and start 
>creating apps. Another motivation is that in some situations (std) library 
>features shipped with the compiler work better with tools (debuggers, 
>profilers, embedded, etc.). Any scenario adding support for C++11 would 
>clearly need to be optional and not impact current users. 

                
> Multiple C++ Windows, OSX, and iOS portability issues
> -----------------------------------------------------
>
>                 Key: THRIFT-1753
>                 URL: https://issues.apache.org/jira/browse/THRIFT-1753
>             Project: Thrift
>          Issue Type: Bug
>          Components: C++ - Library
>    Affects Versions: 0.9, 1.0
>         Environment: Windows MSVC10, MSVC11
> OSX GCC-4.2
> iOS Clang-4.0
>            Reporter: Ben Craig
>             Fix For: 0.9.1
>
>         Attachments: cleaner_port3.patch, cleaner_port4.patch
>
>
> These are all in the C++ library.  Here is a summary of what I changed. 
> All of these fixes make a ~5000 line patch (though a lot of that is 
> deleted lines).
> *   General cleanup of the msvc project
> *   Using HAVE_CONFIG_H instead of force including files
> *   Getting rid of some unnecessary files (stdafx.*, TargetVersion.h)
> *   Significant rework of windows portability.  No longer using config.h 
> and force_inc.h to make Windows look like *nix.  Instead, making lots of 
> Thrift specific #defines that are vaguely *nixy, and having those forward 
> to *nix or Windows stuff appropriately.  For example, THRIFT_CTIME_R calls 
> ctime_r on *nix, and a wrapper thrift_ctime_r on Windows.  The old 
> approach doesn't work when multiple libraries attempt the same trick.  For 
> example, if openssl #defined errno to ::WSAGetLastError() as well, then 
> that would cause problems.
> *   Adding preprocessor flag that can optionally squelch console output. 
> Default behavior is unchanged.  Console output is great for home deployed 
> server apps, but it looks unprofessional for consumer apps.
> *   Adding THRIFT_UNUSED_VARIABLE helper macro, to aid in squelching 
> warnings.
> *   Adding redirector header for <functional> and <tr1/functional>.  Since 
> namespaces aren't consistent (std vs std::tr1), I have added symbols to 
> the apache::thrift::stdcxx namespace.  This is important for Clang / iOS 
> support
> *   usleep and sleep on Windows were both sleeping in milliseconds.  sleep 
> now correctly sleeps for seconds, and usleep attempts to sleep for 
> microseconds (after converting very coarsely to milliseconds).
> *   Adding support for using C++11 std::thread (and mutex, and monitor). 
> Thrift already supported boost::thread and posix threads.  Clients that 
> use std::thread no longer need built boost libraries.  The boost headers 
> are sufficient for them.  Switching from boost::thread to std::thread 
> resulted in a ~50k reduction in exe size in my tests.  By default, msvc10 
> and below will use boost::thread, msvc11 and up will use std::thread.
> *   Fixing more 64-bit socket truncation issues in non-blocking server and 
> ssl support.  openssl itself has socket truncation issues, so I could not 
> fix them all.
> *   Fixed THRIFT-1692 "SO_REUSEADDR allows for socket hijacking on Windows 
> ".  Now using SO_EXCLUSIVEADDRUSE on windows, and SO_REUSEADDR on *nix.
> *   Making TFileTransport use thrift style threads instead of redoing all 
> the pthread+boost stuff itself.
> *   Includes, and builds upon THRIFT-1740 (Make C++ library build on OS X 
> and iOS)
> *   Moved several functions out of thrift/windows/config.h, and into other 
> thrift/windows headers.
> *   Using built-in stdint.h on Windows if available (by checking 
> HAVE_STDINT_H) and 
> using boost typedefs otherwise.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to