>From some quick searching, it looks like C++11 is supported on Ubuntu 14.04 LTS but not on 12.04 LTS. Considering that 14.04 is already nearly 2 years old (and 16.04 comes out soon), I think it is fairly reasonable to depend on C++11 even though 12.04 still has another 2 years of life. Everyone has had 2 years to update to the current LTS.
I only looked into Ubuntu, but I'm guessing that this is about the same for redhat or centos. I think we should stay with C++11 and expect anyone on the old releases to install newer C++ libs if they want to use Parquet-CPP, unless there's some reason I'm missing why this is a more wide-spread problem than it looks like. rb On Mon, Mar 7, 2016 at 9:02 AM, Wes McKinney <[email protected]> wrote: > 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. > > > -- Ryan Blue Software Engineer Netflix
