[gmx-developers] C++ in kernels

[Erik Lindahl]

HI Teemu!

Email is always a bit dangerous/difficult when it comes to tone - sorry if it had too few smileys late a friday night ;-) 

My point wasn’t at all to critize the current C++ code, but to emphasize that we’ve been fine with introducing more C++ features than we originally planned, before saying that there are still some things at least I want us to wait with. You are probably right that the multiple templates are only in testing code - and I frequently have memory like a goldfish. Had I actually been troubled by a specific piece of code, you can trust that I would have complained on redmine.

I don’t think the balance in our C/C++ transition is primarily a technical one (I’m sure C++ is fine technically for at _least_ 99.999%), but more social. We need to strike a balance between introducing enough C++ to make life easy and productive for C++ wizards, while limiting it enough so we don’t cause too much frustration and dropped productivity for non-C++-wizards (hey, that largely includes me :-). I think this means the balance will naturally move much more towards C++ as we go on, but we’ll need to let that take some time!

Then the performance-sensitive routines are separate chapter. Post-5.0 I think we need come up with a better policy on what that really is, and try to limit it severely. Right now we have far too much hardware-specific code that is even more difficult to read than C++ (e.g. SIMD), and finding ways to reduce this will give us more time to spend on the higher-level code - in particular C++ !

Cheers,

Erik








On 11 Jan 2014, at 06:47, Teemu Murtola <teemu.murtola at gmail.com> wrote:

> Hello,
> 
> I do understand your point about testing the C++ support before we use it everywhere, and I don't disagree with that, but your tone just prompts for a response for some of the details. ;)
> 
> On Fri, Jan 10, 2014 at 11:47 PM, Erik Lindahl <erik.lindahl at scilifelab.se> wrote:
> Yes. Remember that after a lot of deliberation we agreed on a compromise to allow _very_ limited amounts of C++. This ended up being pushed to accept a lot more C++ (including Boost, exceptions, etc.).
> 
> Of course it depends on how you view it (and how you define "amounts"; see below my comment on "heavy C++"), but vast majority of the C++ code is currently "simple", in the sense that it only uses very basic C++ constructs (classes, yes, and some inheritance, and occasional simple template).
> 
> I remember the discussion on exceptions, and in the end everyone seemed to agree that this would be the way to go.
> 
> We _still_ don't require anything major from boost except for the boost::exception support that we originally decided on (and the dependencies it already brings with it, which is basically boost::shared_ptr); the only thing added after that is boost::scoped_ptr, and I have hard time believing that would be a bottleneck for anything. By necessity, the use of exceptions requires some usage of smart pointers throughout the code, but even this is fairly limited.
>  
> The decision we made about only allowing single templates also appear to have been broken rapidly...
> 
> Could you perhaps elaborate? There is a _single_ instance of a template with multiple parameters in the code (outside test code). That particular template has been there from the start, and I remember in 2010 explicitly showing _you_ the code and _specifically_ asking whether this part was too complex. And you said no. The test code can always be disabled, and doesn't affect the ability to compile mdrun or its performance.
> 
> Most other uses of templates are in specifying the contained type for a container-like class, in very simple classes, or in individual methods where they reduce the amount of boilerplate code the caller needs to use, hopefully reducing the potential for bugs. There is no partial specialization, there shouldn't be templated overloads with non-trivial resolution rules, no SFINAE, no type traits, etc. If you mean something else, please clarify. 
> 
> If you want to restrict passing templated types as template parameters to other classes, then note that also, e.g., std::vector has multiple template parameters, and the allocator itself (the second parameter, which has a default value) is a template.
>  
> Remember that most developers are not professional C++ programmers, and I’m a bit worried that large parts of the code are turning into pretty heavy C++.
> 
> Again, this depends on your definition of "heavy". If you define it as "over 10% of this source file would not compile with a C compiler", then yes, but is that really the definition you want? As said above, vast majority of the code only uses very basic C++ constructs, and I would not call that "heavy", even though it is 100% C++, and not C. And nearly all of the C++ code is documented, at least on some level, which hopefully lowers the barrier. I'm willing to (and I hope other people would be, too) to improve the documentation, but that would be more efficient if others would actually specify what parts they would like to have improved.
> 
> My impression is that very few are really interested in (or maybe rather, does not have the time to) actually discuss any details related to C++, on the level that would lead to some concrete results. In such an environment, if we had just waited to have a common agreement on every single detail, with everyone explicitly voicing that agreement, we (I) would probably not have written a single line of code in the past 2-3 years… Maybe that would have been best for my sanity, but it's hard to say where we would be if that were the case. Since Gerrit came to use, I have simply pushed up small incremental work, not trying to introduce any additional C++ features without a very good reason (and those have been very few, and most have been discussed at least in Redmine). I've yet to see a specific, concrete complaint on where people would like to have "simpler" C++ or "less heavy" C++.
> 
> Just some (or maybe quite a few) thoughts,
> Teemu
> -- 
> Gromacs Developers mailing list
> 
> * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before posting!
> 
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> 
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers or send a mail to gmx-developers-request at gromacs.org.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20140111/883f0242/attachment-0001.html>