[gmx-developers] C++ in kernels

Teemu Murtola teemu.murtola at gmail.com
Sat Jan 11 06:47:37 CET 2014


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20140111/5b85fc64/attachment.html>


More information about the gromacs.org_gmx-developers mailing list