<div dir="ltr">Hello,<br><div class="gmail_extra"><br></div><div class="gmail_extra">I do understand your point about testing the C++ support before we use it everywhere, and I don&#39;t disagree with that, but your tone just prompts for a response for some of the details. ;)<br>
<br><div class="gmail_quote">On Fri, Jan 10, 2014 at 11:47 PM, Erik Lindahl <span dir="ltr">&lt;<a href="mailto:erik.lindahl@scilifelab.se" target="_blank">erik.lindahl@scilifelab.se</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div>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.).</div>
</div></blockquote><div><br></div><div>Of course it depends on how you view it (and how you define &quot;amounts&quot;; see below my comment on &quot;heavy C++&quot;), but vast majority of the C++ code is currently &quot;simple&quot;, in the sense that it only uses very basic C++ constructs (classes, yes, and some inheritance, and occasional simple template).</div>
<div><br></div><div>I remember the discussion on exceptions, and in the end everyone seemed to agree that this would be the way to go.</div><div><br></div><div>We _still_ don&#39;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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>The decision we made about only allowing single templates also appear to have been broken rapidly...</div>
</div></blockquote><div><br></div><div>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&#39;t affect the ability to compile mdrun or its performance.</div>
<div><br></div><div>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&#39;t be templated overloads with non-trivial resolution rules, no SFINAE, no type traits, etc. If you mean something else, please clarify. </div>
<div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>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++.</div>
</div></blockquote><div><br></div><div>Again, this depends on your definition of &quot;heavy&quot;. If you define it as &quot;over 10% of this source file would not compile with a C compiler&quot;, 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 &quot;heavy&quot;, 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&#39;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.</div>
<div><br></div><div>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&#39;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&#39;ve yet to see a specific, concrete complaint on where people would like to have &quot;simpler&quot; C++ or &quot;less heavy&quot; C++.</div>
<div><br></div><div>Just some (or maybe quite a few) thoughts,</div><div>Teemu</div></div></div></div>