hello, responses inline
On Mon, Mar 7, 2016 at 8:22 AM, Aliaksei Sandryhaila <[email protected]> wrote: > Hi Wes and Julien, > > At this point, parquet-cpp is heavily reliant on C++11 features and > semantics. Believe it or not :), there are plenty of companies still > running older versions of Linux that do not support C++11. Removing this > dependency will make parquet-cpp usable (and much more appealing) to them. > Just to be clear -- is this a problem for you specifically? Any other context would be helpful. It is not especially difficult to set up a portable C++11 build toolchain even on Linux distributions that do not have a new enough gcc in their package repository. Both Impala and Kudu have recently developed isolated 3rd-party toolchains to facilitate development and packaging for these systems. See for example https://github.com/cloudera/native-toolchain > We would like to make parquet-cpp C++09 compatible. The end goal is to have > a library that can compile with and without --std==c++11 flag. There are two > parts of this process. The first one is to redefine or remove C++11 > keywords, such as auto, unique_ptr, std::move, or for( : ) loops. The other > part is to evaluate our use of C++11 features that are harder to replace, > such as shared_ptr, make_shared(), etc., and either write our own > implementation for this or modify code where appropriate (such as replace > shared_ptr with unique_ptr where possible). > > We can do this either by maintaining a separate feature branch and > periodically pulling new code from parquet-cpp; or by implementing the > compatibility functionality directly in parquet-cpp (all future PRs will be > tested for c++09 compatibility during CI builds). > I'm fairly negative on dropping C++11 in trunk / main library development -- it would be a hardship for me personally, and additionally deter software engineers who are increasingly coming back to C++ development because of C++11/14. This leaves legacy C++<11 projects that wish to use parquet-cpp as a 3rd-party dependency somewhat out in the cold. One approach is to provide a wrapper API for projects that cannot interact with APIs that use C++11 facilities (like std::unique_ptr). The same approach could be used to provide a C API for the project. A wrapper API would be much easier to maintain and test without having a separate branch to keep in sync -- there might be some pitfalls here that I'm not aware of so let me know what you think. Thanks, Wes > What are your thoughts on this? > > Thank you, > Aliaksei. >
