Re: [Rdkit-devel] The RDKit and modern C++

[David C. <dav...@gm...>]

Hi Greg et al,

You can increment by one the number of large organisations still not fully
converted to RH6!  It's a real pain for me as a developer. I have been
unable to build the latest few releases of Qt 5 on a RH6 machine with the
system g++4.4, for example.  However, my experience developing code for a
large organisation with hardware dispersed over a number of sites each with
its own peculiarities of linux support is that it's essential that the
final production version is built with the default system compiler for the
target OS. Otherwise you get compatibility issues with missing libraries,
wrong version of glib etc.  This means that I am still having to compile
some code with g++4.1 on RH5. I don't know why RedHat is so behind with its
compiler support, but whilst it is I would need to continue to be able to
build code with g++4.4.  Your idea of a compatibility branch is a good
stopgap. Having said that I wonder if, in practice, it's much different
from just saying if you have an old compiler you need to use an older
version of RDKit that works with it. You might maybe promise to fix, or
help affected people to fix, the most egregious(*) of bugs in the last
version supported by the older compiler, but no more than that.  I think
this would be an acceptable stance to take - the fact that the compiler I
use can't support a standard that's nearly 4 years old is surely my problem
and shouldn't be an excuse to hold everyone else up.

Cheers,
Dave

(*) And from what I see, the quality of the testing is such that that is an
exceptionally rare thing.


On Tue, May 12, 2015 at 5:32 AM, Greg Landrum <gre...@gm...>
wrote:

> Dear all,
>
> I would like to start "allowing" the use of modern C++ (by which I mean C
> ++11/14) in the RDKit. I think this is an important step both for code
> quality in the toolkit itself and for allowing us (the developers) to
> continue to learn and use modern tools. Who knows, it may even help with
> performance. :-)
>
> This move would, of course, break compatibility with some older compilers.
> Here's one view of compiler support for C++11 and some of C++14:
> http://en.cppreference.com/w/cpp/compiler_support
>
> It looks like g++ 4.8+ and VC++ 2013 are both fine with most/all C++11 features.
> VC++ 2015 does even better and g++5 is very solid. Clang, which is the
> default on the Mac and available for both windows and linux, has great
> support.
>
> The thing I am most concerned about is that RHEL6 only includes g++ 4.4.
> RHEL7 is fine, but I would guess that most large organizations aren't that
> up-to-date yet. I know of at least one (ahem) that is hasn't even finished
> the move to RHEL6. It looks like an "enterprise" alternative here is to use
> the RedHat Developer Toolset, but I don't have personal experience with
> that yet. Clang is always an option, but it something people will have to
> install on their own.
>
> Here's how I would propose that we proceed:
>  - If no fundamental objections come up here, we'll create a document
> listing the C++ features that should not be used (yet) due to compiler
> compatibility. We'll also agree on a new baseline version of Boost that can
> be assumed to be present.
>  - I will create a compatibility branch based on the current master. Bug
> fixes will be ported back onto this branch for the next release or two, but
> new features will not be added.
>  - We can start using modern C++ on master.
>
> Best,
> -greg
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Rdkit-devel mailing list
> Rdk...@li...
> https://lists.sourceforge.net/lists/listinfo/rdkit-devel
>
>