<div dir="ltr">Hi,<br><div class="gmail_extra"><br>On Fri, Mar 15, 2013 at 9:49 AM, David van der Spoel <span dir="ltr"><<a href="mailto:spoel@xray.bmc.uu.se" target="_blank">spoel@xray.bmc.uu.se</a>></span> wrote:<br>
<div class="gmail_quote"><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 style>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'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 style><br></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">
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 style>
I'm not sure what you are suggesting here. I'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<bool> vs std::vector<gmx_bool> (which most people wouldn'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 style><br></div><div style>Teemu</div></div></div></div>