<br><br><div class="gmail_quote">On Fri, Mar 15, 2013 at 1:32 PM, Teemu Murtola <span dir="ltr">&lt;<a href="mailto:teemu.murtola@gmail.com" target="_blank">teemu.murtola@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hi,<br><div class="gmail_extra"><div class="im"><br>On Fri, Mar 15, 2013 at 9:49 AM, David van der Spoel <span dir="ltr">&lt;<a href="mailto:spoel@xray.bmc.uu.se" target="_blank">spoel@xray.bmc.uu.se</a>&gt;</span> wrote:<br>

</div><div class="gmail_quote"><div class="im"><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">First is about header file name. Since we will for the foreseeable future at least have both C and C++ code it would be good in my opinion to have a clear distinction in file names. The C++ files have extension .cpp throughout, but the header files are .h. I would like to propose to mv those to .hpp.<br>

</blockquote><div><br></div></div><div>I seem to recall that this was discussed back in 2009, and the decision was to have a single .h extension (e.g., the wiki pages, written mainly at that time, talk about .c/.cpp, but only of .h). If you want to revert that decision (or some other guidelines), I suggest you also factor in the effort that converting existing code (~200 files and ~70k lines) to the new rules. While not that big in this case, it is still annoying to try to track guidelines that seem to change every time someone starts to work on C++ code... That said, I don&#39;t have that strong feelings about this particular header extension. You should still specify when a header should have which extension. E.g., if a header has a bunch of code behind #ifdef __cplusplus, and is otherwise C-compatible, what should it be? I suspect that this kind of headers will be common during a transition period (which can be quite long...). Right now, smalloc.h is an example.</div>
</div></div></div></blockquote><div><br></div><div>I see. I am also happy with retaining just .h and using file location to imply whether C++ conversion has occurred, or not.</div><div><br></div><div>I am currently thinking that a large number of our existing .h header files will gradually die as the functions and structures they declare become encapsulated objects (and even our relatively well-behaved opaque-pointer C objects will probably get renamed). There should be very little that ends up being just a file or text copy - there&#39;s too many things that need thinking about. So, I think the issue of relabelling a header file will not arise much under any policy.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im"><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">

Second is the use of bool versus gmx_bool. I was convinced at first that bool was the way to go, but of course this is not portable to C code, so it is probably better to stick with gmx_bool.</blockquote><div><br></div></div>
<div>
I&#39;m not sure what you are suggesting here. I&#39;m not sure what we want to do with C compatibility in the long run, but given that gmx_bool behaves badly with equality comparison (both in C and C++ code) and with overloading (in C++ code), I think it is a worse alternative than bool in code that is not forced to be C compatible. The only advantage I see with gmx_bool is the behavior of std::vector&lt;bool&gt; vs std::vector&lt;gmx_bool&gt; (which most people wouldn&#39;t probably notice, though, so it is very minor issue). Would you really want to ban using a basic C++ feature that can actually help catch very unintuitive errors?</div>
</div></div></div></blockquote><div><br></div><div>Oh, I see. I now recall that gmx_bool is typedef&#39;ed to an int, and in C++ that is distinct from bool (and vector&lt;bool&gt; is specialized to work as a bitfield, IIRC).</div>
<div><br></div><div>In that case, using bool in code we write as C++ makes sense. Code imported from C should be refactored to use bool as part of the process. Getting help from the compiler is much more important than the hypothetical benefit of wanting to re-typedef our in-house boolean type some later time.</div>
<div><br></div><div>I don&#39;t think we want to add a C++-only typedef of bool to gmx_new_bool (or whatever), either.</div><div><br></div><div>Mark</div></div>